Hi,
First of all would just like to say that puppy is brilliant and hopefully marks the end of a long search for a distribution that meets all my needs. Currently using version 2.13 running on a cyrix iii (samuel) 700mhz with 384 mb ram.
Whilst I have messed around with quite a few different distros desktop wise, I am still a very much a newbie in terms of configuration aand command line.
I want to use puppy for audio and am keen to make use of the realtime capability for low latency operation now included since 2.6.17. The alsa wiki advises that this should be done simply by adding
@audio - rtprio 99
@audio - memlock 250000
@audio - nice -10
to /etc/security/limits.conf.
Is there an equivalent location in puppy? I am unable to identify this path or an equivalent in the /etc directory. Can anyone confirm that the realtime modules are included in the puppy build?
Any help would be greatly appreciated.
Cheers,
Ross
How to enable real time audio in Puppy?
PAM
I found out that the /etc/security directory mentioned in my first post is directly related to the Plugable Authentication Modules (PAM) system which does seem to be included in the vanilla kernel, but not puppy. Appreciate this must be for size issues.
Therefore real time operation can not simply be enabled. Can anyone advise the most painless way to get realtime operation in puppy?
I suspect might have to recompile the kernel with the appropriate patches/modules.
Cheers,
Ross
Therefore real time operation can not simply be enabled. Can anyone advise the most painless way to get realtime operation in puppy?
I suspect might have to recompile the kernel with the appropriate patches/modules.
Cheers,
Ross
-
Dougal
- Posts: 2502
- Joined: Wed 19 Oct 2005, 13:06
- Location: Hell more grotesque than any medieval woodcut
I'm not sure, but I think you need to recompile the kernel with the "low latency" option.
BTW, if you look in the directory /lib/modules you'll find a file named "DOTconfig"-something-or-other which is the kernel configuration file, which will show you which options are built into Puppy's kernel, which were compiled as modules and which are completely absent…
You should try looking at the thread about a "audio optimised Puppy" (or "multimedia", I can't remember) that Plinej started a while ago.
BTW, if you look in the directory /lib/modules you'll find a file named "DOTconfig"-something-or-other which is the kernel configuration file, which will show you which options are built into Puppy's kernel, which were compiled as modules and which are completely absent…
You should try looking at the thread about a "audio optimised Puppy" (or "multimedia", I can't remember) that Plinej started a while ago.
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Some say your nose
Some say your toes
But I think it's your mind
Thanks Dougal.
will check the modules tonight, but certainly the PAM system doesnt seem to have been included which would indicate it is not an available feature. I had resigned myself to the fact that the kernel would have to be recompiled which looks ok to do.
Checked Plinej's multimedia thread - doesnt appear to be patched, but might be a better starting point for what I want to do. Im trying to optimise for the cyrix right now, which is pretty poor. Plinej has chosen fluxbox, but I think JWM is actually lighter on older specs?
Cheers,
Ross
will check the modules tonight, but certainly the PAM system doesnt seem to have been included which would indicate it is not an available feature. I had resigned myself to the fact that the kernel would have to be recompiled which looks ok to do.
Checked Plinej's multimedia thread - doesnt appear to be patched, but might be a better starting point for what I want to do. Im trying to optimise for the cyrix right now, which is pretty poor. Plinej has chosen fluxbox, but I think JWM is actually lighter on older specs?
Cheers,
Ross
Seems to be some confusion over terms & configurations.
PAM is not part of kernel - it IS an additional security feature which may be implemented on an existing configuration.
Use of niceness factoring is not altering latency defaults.
Real time is not a latency issue > please Google for UML mode.
HTH
PAM is not part of kernel - it IS an additional security feature which may be implemented on an existing configuration.
Use of niceness factoring is not altering latency defaults.
Real time is not a latency issue > please Google for UML mode.
HTH
-
tempestuous
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
Rossco,
Low latency audio once required modifications to the kernel, but the latest 2.6 kernels should be fine as-is.
See http://lowlatency.linuxaudio.org/
According to the Jack homepage http://jackit.sourceforge.net/docs/faq.php#a52 non-root users need to gain real-time scheduling privileges - I think that's what PAM can provide, but since Puppy runs as root this is not an issue.
The major factor will be your sound card. Are you doing multitrack midi? I suggest SB Audigy as minimum spec.
Low latency audio once required modifications to the kernel, but the latest 2.6 kernels should be fine as-is.
See http://lowlatency.linuxaudio.org/
According to the Jack homepage http://jackit.sourceforge.net/docs/faq.php#a52 non-root users need to gain real-time scheduling privileges - I think that's what PAM can provide, but since Puppy runs as root this is not an issue.
The major factor will be your sound card. Are you doing multitrack midi? I suggest SB Audigy as minimum spec.
Thanks for all the replies.
I think it should be possible to get low latency working without recompiling, as stated above. Anyway, it seems if I were to apply the same configuration file to the patched kernel I would have to do the same fiddling to get it all working.
I have to say I am very confused when it comes to which low latency solution to use. The page linked above suggests use of Andrew Mortons patches, others will state to use Ingo Molnars and Con Kovalis also has patches. To make matters worse the term 'real time' is banded about like it is inseperable from low latency, hence why I have got that impression. I think elements of both Ingo and Cons work has been included in the kernel since 2.6.17
Whilst I recognise that PAM is for user authentication, I believe the latest incarnations of it work with the LSM module (linux security module) to grant real time priviledges to non-root users for audio applications (I understand now that in Puppy I am always root). This apparently has been the preferred method of providing low latency for some time, JACK are not the only ones to advise this the alsa wiki, amongst many others, do to
http://alsa.opensrc.org/RealtimeKernelAndPAM
I will try the guide in the above link, PAM is obviously not needed here.
As for soundcard, I wouldn't use an audigy (have one in another pc) as it resamples everything to 48khz, and badly degrading sound quality. Will even resample 48Khz material. I have a via envy24ht-s based card. This is actually another issue. Puppy recognises this as an ice1724 card when infact it is an ice1712 card. Both drivers are enabled in the config file so I dont know what is going on here. I do get sound though. Will look into this as well.
Cheers,
Ross[/url]
I think it should be possible to get low latency working without recompiling, as stated above. Anyway, it seems if I were to apply the same configuration file to the patched kernel I would have to do the same fiddling to get it all working.
I have to say I am very confused when it comes to which low latency solution to use. The page linked above suggests use of Andrew Mortons patches, others will state to use Ingo Molnars and Con Kovalis also has patches. To make matters worse the term 'real time' is banded about like it is inseperable from low latency, hence why I have got that impression. I think elements of both Ingo and Cons work has been included in the kernel since 2.6.17
Whilst I recognise that PAM is for user authentication, I believe the latest incarnations of it work with the LSM module (linux security module) to grant real time priviledges to non-root users for audio applications (I understand now that in Puppy I am always root). This apparently has been the preferred method of providing low latency for some time, JACK are not the only ones to advise this the alsa wiki, amongst many others, do to
http://alsa.opensrc.org/RealtimeKernelAndPAM
I will try the guide in the above link, PAM is obviously not needed here.
As for soundcard, I wouldn't use an audigy (have one in another pc) as it resamples everything to 48khz, and badly degrading sound quality. Will even resample 48Khz material. I have a via envy24ht-s based card. This is actually another issue. Puppy recognises this as an ice1724 card when infact it is an ice1712 card. Both drivers are enabled in the config file so I dont know what is going on here. I do get sound though. Will look into this as well.
Cheers,
Ross[/url]
-
tempestuous
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
You clearly have a high quality sound card. MAudio perhaps?Rossco wrote:I have a via envy24ht-s based card.
I helped a musician friend set up a low-latency midi system using just such a sound card under RedHat9 back in 2003.
Yes, we patched the 2.4.22 kernel with the patches you mentioned. My understanding is that many/most of these innovations are now standard. I remember that a key kernel option was "Preemptible kernel". I just had a look at Puppy's kernel config and I see there is still such a setting: Processor type and features > Preemption Model > Preemptible Kernel (Low-Latency Desktop)
and this setting is not enabled. You might consider recompiling with just this one adjustment.
Success was very easy to measure. When you press a key on the midi keyboard, you want to hear its effect (via the sound card) instantly. Any noticeable delay means failure.
At that time we were using the MIDI sequencer "MusE" http://www.muse-sequencer.org/
I didn't know that Audigy did such bad things. I do know it's the cheapest sound card available with a low-latency "ASIO" driver under Window$.
Yes Flash, I think it was some of the Con Kovalis stuff that has been suggested as being useful to all users, but some of these approaches are granting high priority to audio applications and processes over others. This obviously is not suitable for those who do not need low latency audio. I think Desktop latency, as mentioned by tempestuous, would be useful for all users, but I am not sure if this is the same premption settings that maximise audio latency performance?
There are apparently system security issues in enabling some low latency settings as root user, and AFAIK this is where PAM and the LSM module come in. I have read many times that users should not operate as root unless necessary. Being a total newbie, Im only vaguely aware of why this is, and am a little confused as to why in puppy the user is always root, and this is not considered an issue.
tempestuous -
My soundcard was actually quite inexpensive (20GBP), but yes realtively good. It is an unbranded card similar to the chaintech av710-(which isnt available in the EU). The envy chips in these are similar to the maudio audiophile (its the envy24ht, mine the ht-s), and have reasonable wolfson DACS on the last 2 of 8 channels. Mine has optical in and out, and something i got quite excited about was when i ntoiced that the ice1724 driver works with it - this has the potential to allow sync of the card to an external clock via spdif in. However, not sure if this is a chip feature or a driver only feature. The maudio implementations will have better DACs and larger internal buffers.
Audigys are only one of many cards that resample - you dont necessarily have to spend more to avoid it though (some cheap c-media chips dont). free Asio4all drivers work with most soundcards on window$. Without asio, window$ mixer will also badly resample and I believe dmix (often enabled as default, not yet sure in puppy) in alsa will also do the same if your card doesnt support hardware mixing. using the hwdevices plug in alsa will dump the audio stream straight to soundcard avoiding the cpu load of resampling and the lower audio quality that results from it.
I am still to learn how to recompile and change configs - but Im sure this has been covered many times in the forum, will wait until I have more specific questions I cant answer myself.
Ross
There are apparently system security issues in enabling some low latency settings as root user, and AFAIK this is where PAM and the LSM module come in. I have read many times that users should not operate as root unless necessary. Being a total newbie, Im only vaguely aware of why this is, and am a little confused as to why in puppy the user is always root, and this is not considered an issue.
tempestuous -
My soundcard was actually quite inexpensive (20GBP), but yes realtively good. It is an unbranded card similar to the chaintech av710-(which isnt available in the EU). The envy chips in these are similar to the maudio audiophile (its the envy24ht, mine the ht-s), and have reasonable wolfson DACS on the last 2 of 8 channels. Mine has optical in and out, and something i got quite excited about was when i ntoiced that the ice1724 driver works with it - this has the potential to allow sync of the card to an external clock via spdif in. However, not sure if this is a chip feature or a driver only feature. The maudio implementations will have better DACs and larger internal buffers.
Audigys are only one of many cards that resample - you dont necessarily have to spend more to avoid it though (some cheap c-media chips dont). free Asio4all drivers work with most soundcards on window$. Without asio, window$ mixer will also badly resample and I believe dmix (often enabled as default, not yet sure in puppy) in alsa will also do the same if your card doesnt support hardware mixing. using the hwdevices plug in alsa will dump the audio stream straight to soundcard avoiding the cpu load of resampling and the lower audio quality that results from it.
I am still to learn how to recompile and change configs - but Im sure this has been covered many times in the forum, will wait until I have more specific questions I cant answer myself.
Ross
-
Dougal
- Posts: 2502
- Joined: Wed 19 Oct 2005, 13:06
- Location: Hell more grotesque than any medieval woodcut
It could be that the ALSA wizard has misdetected your card… tryRossco wrote:I have a via envy24ht-s based card. This is actually another issue. Puppy recognises this as an ice1724 card when infact it is an ice1712 card. Both drivers are enabled in the config file so I dont know what is going on here. I do get sound though. Will look into this as well.
Code: Select all
rmmod ice1724Code: Select all
modprobe ice1712You can probably do a text search in /etc (with Turma, or in a terminal: "fgrep -r 'ice1724' /etc/*") to see where that module is listed for loading at bootup and just change it to ice1712.
You might want to search a bit for messages by the user "toddiejoe" (or something similar) who created quite a few dotpups with collections of audio apps and wrote good explanations about them.
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Some say your nose
Some say your toes
But I think it's your mind
Tempestuous
I couldnt find the Preemption Model > Preemptible Kernel (Low-Latency Desktop) in the config file. There is CONFIG_PREEMPT which I think may be pretty much the same option - this should give full preemption when enabled after recompiling. Not sure why im not seeing the same options as you.
I believe the method as you described will enable optimum low latency for audio. I see voluntary preemption is already enabled.
I saw on config file for the latest preemption patched kernel which has a CONFIG_PREEMPT_RT (Enabled) option in addition to CONFIG_PREEMPT (Not enabled) this appears to be missing from the puppy file - I will perhaps have to patch to get this if I can establish that it is worthwhile.
BTW read in the manual the reasoning behind puppy only having a root user and fully understand the issue now. Thanks all.
Ross
I couldnt find the Preemption Model > Preemptible Kernel (Low-Latency Desktop) in the config file. There is CONFIG_PREEMPT which I think may be pretty much the same option - this should give full preemption when enabled after recompiling. Not sure why im not seeing the same options as you.
I believe the method as you described will enable optimum low latency for audio. I see voluntary preemption is already enabled.
I saw on config file for the latest preemption patched kernel which has a CONFIG_PREEMPT_RT (Enabled) option in addition to CONFIG_PREEMPT (Not enabled) this appears to be missing from the puppy file - I will perhaps have to patch to get this if I can establish that it is worthwhile.
BTW read in the manual the reasoning behind puppy only having a root user and fully understand the issue now. Thanks all.
Ross
Did someone mention my name? 
When I wanted a low-latency Puppy for strictly audio and MIDI work, I recompiled the 2.4.29 kernel for Puppy 1.0.8rc1 with the Ingo patches. It worked fine and ended up with a kernel only slightly larger than the original. At the time, I read in several places that the new realtime improvements to the 2.6 kernel were still slower than a properly-recompiled, low-latency 2.4 kernel so I never bothered trying to improve the 2.6 kernel Puppy versions. I have not looked at kernel recompiling or the newest Puppy updates in a few months so I have little in the way of help with the 2.6 kernel. Funny thing, my audio/MIDI computer is still a heavily-customized Puppy 1.0.8rc1 because I got everything to work so well together for it.
Good luck and keep us all posted!
When I wanted a low-latency Puppy for strictly audio and MIDI work, I recompiled the 2.4.29 kernel for Puppy 1.0.8rc1 with the Ingo patches. It worked fine and ended up with a kernel only slightly larger than the original. At the time, I read in several places that the new realtime improvements to the 2.6 kernel were still slower than a properly-recompiled, low-latency 2.4 kernel so I never bothered trying to improve the 2.6 kernel Puppy versions. I have not looked at kernel recompiling or the newest Puppy updates in a few months so I have little in the way of help with the 2.6 kernel. Funny thing, my audio/MIDI computer is still a heavily-customized Puppy 1.0.8rc1 because I got everything to work so well together for it.
Good luck and keep us all posted!
-
tempestuous
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
A Pre-empting kernel was the BIG change somewhere in 2.4_xx versions
2.6_xx has vastly enhanced the latency potential
Users who knew how - always had ability to alter system defaults
Now - it is more accessible & and (arguably) slightly less daunting.
Other kernel maintainers - outside of Torvald's tree:
have varied patches that may be employed.
As stated before, PAM is the enhanced security wrapper -
HOW it is used - OR whether to even use it MAY be of benefit to varied Apps -
ABI & Esp. API > user sycalls are configurable -
please do not confuse default behaviour
to what is the requisite requirements of ANY App !
2.6_xx has vastly enhanced the latency potential
Users who knew how - always had ability to alter system defaults
Now - it is more accessible & and (arguably) slightly less daunting.
Other kernel maintainers - outside of Torvald's tree:
have varied patches that may be employed.
As stated before, PAM is the enhanced security wrapper -
HOW it is used - OR whether to even use it MAY be of benefit to varied Apps -
ABI & Esp. API > user sycalls are configurable -
please do not confuse default behaviour to what is the requisite requirements of ANY App !
Gn2 Im not really sure what you are saying here. I thought I understood what PAM is and am not sure where you think my confusion lies. I realise I started the thread without fully understanding what PAM does, but after reading some high level instructions on setting up low latency at that point I had no reason to dig deeper. You then corrected me.As stated before, PAM is the enhanced security wrapper -
HOW it is used - OR whether to even use it MAY be of benefit to varied Apps -
ABI & Esp. API > user sycalls are configurable - Crying or Very sad please do not confuse default behaviour
to what is the requisite requirements of ANY App !
Am I wrong in saying that PAM, in distributions that have it included and have kernels which can provide low latency functionality without patching, plays some role in providing non root users with this functionality? I know this isn't PAMs only or main purpose and that I dont need it in this instance.
Need to get a flash drive to be able to do anything, hope to report back in the next few days.
Ross
My intent was not to correct - (there is no correct - just alternate Cfg's)
A guide - to possible need to re-examine all options
ALL later 2.6_xx Linux kernels have pre-empting & latency pre-defined .
2.4 kernels had limited pre-emption features:
Hence the user had to dig in & alter to specific needs using makefile options -
Then editing system wide permission bits.
Makefile options varied by kernel version (Plse see kernel change logs)
There is every likelihood PAM usage may be avoided for your needs.
It does enable stacking commands & finer -grained session control
(Sand-box has even more Sys/Admin defined per-session permission features).
Backup all sytem critical Cfg's - Esp the now usable bzImage.
Do not edit any without saving original first
Do NOT re-compile kernel by using (mrproper, clean) or (make oldconfig)
Pam may require additional Python dependencies.
If Python or Pam gets mis-Cfg'd - Pam log-on will lock you out of system !
In manner never encountered before.
NO logon will be possible - Incl - NO remote logon
Subsequent repairs are no simple task.
Requires chroot/bind & far more CLI pre-knowledge.
Probably why VERY few platforms supply PAM as default inclusion.
Gentoo is one
It is advisable for most > be very cautious employing own changes to defaults of security.
Puppy is NOT generic Linux !
= Does not include some essential (in this case Esp) CLI tools
A guide - to possible need to re-examine all options
ALL later 2.6_xx Linux kernels have pre-empting & latency pre-defined .
2.4 kernels had limited pre-emption features:
Hence the user had to dig in & alter to specific needs using makefile options -
Then editing system wide permission bits.
Makefile options varied by kernel version (Plse see kernel change logs)
There is every likelihood PAM usage may be avoided for your needs.
It does enable stacking commands & finer -grained session control
(Sand-box has even more Sys/Admin defined per-session permission features).
Backup all sytem critical Cfg's - Esp the now usable bzImage.
Do not edit any without saving original first
Do NOT re-compile kernel by using (mrproper, clean) or (make oldconfig)
Pam may require additional Python dependencies.
If Python or Pam gets mis-Cfg'd - Pam log-on will lock you out of system !
In manner never encountered before.
NO logon will be possible - Incl - NO remote logon
Subsequent repairs are no simple task.
Requires chroot/bind & far more CLI pre-knowledge.
Probably why VERY few platforms supply PAM as default inclusion.
Gentoo is one
It is advisable for most > be very cautious employing own changes to defaults of security.
Puppy is NOT generic Linux !
= Does not include some essential (in this case Esp) CLI tools
No sorry "correct" was a bad choice of word - useful prompting.
See the potential problem with PAM, but am not considering it as this approach is clearly aimed at the few multiuser systems that include it as standard.
At this point, do you see any reason why enabling the CONFIG_PREEMPT and recompiling would cause any problems in Puppy? In terms of preemption this seems to be the optimum available setting in the current puppy kernel. CONFIG_PREEMPT_RT is apparently a more extreme setting, which might be better, but this would have to be patched in I think.
Thanks,
Ross
See the potential problem with PAM, but am not considering it as this approach is clearly aimed at the few multiuser systems that include it as standard.
At this point, do you see any reason why enabling the CONFIG_PREEMPT and recompiling would cause any problems in Puppy? In terms of preemption this seems to be the optimum available setting in the current puppy kernel. CONFIG_PREEMPT_RT is apparently a more extreme setting, which might be better, but this would have to be patched in I think.
Thanks,
Ross