On Wed, 7 Oct 2009 21:05:15 +0200 Lennart Poettering <lennart at poettering.net> wrote: > On Wed, 07.10.09 10:43, stan (gryt2 at q.com) wrote: > > > Hi, > > > > Just some possible features to add to pulse to make if easier to > > use. > > > > When the pa_simple model is used and the pa_simple object is > > returned, return the server's default rate, channels, and format in > > the struct so an application can decide if they want to conform to > > reduce the need for resampling. > > We do have a negotiation API similar to this in the complex > API. The simple protocol really should just be simple, and that's > it. I have no plans in adding any additional APIs to it. Fair enough. > > > When pulse chooses its default configuration, it should query the > > sound device to determine the native rates and formats it supports, > > and choose one of them so it doesn't have to do resampling. I have > > an onboard NVIDIA CK8S chip that doesn't do 44100 natively, only > > 48000. Yet pulse is using 44100 as its default configuration for > > that device. > > PA only uses native sampling rates. We always did, always will. We > explicitly disable resampling when opening the audio devices > (SND_PCM_NO_AUTO_RESAMPLE). We only resample if an application then > tries to connect to a sink with a non-matching sample spec. > So that means that the default is only a suggestion. But unless I use the complex model, I have no way of knowing the actual default. It seems that to match pulseaudio and control resampling, the complex is the way to go. I looked at the mainloop model as a simpler alternative to the threaded-mainloop, and giving it a time of -1 for the poll might do what I want, which is to control the loop myself by using nanosleep, perhaps in a separate thread that only deals with sending sound to pulseaudio. And maybe I'll just punt, letting the default pulseaudio-alsa take care of everything. > > If there are no other applications using pulse, and it receives a > > request for a rate, format, or channel configuration different than > > the default, and if the requested format is supported natively on > > the sound device, it switches to that as its default configuration > > for the duration of the request. > > Has been requested before. I don't think this makes sense. Just think > of this: we're idle, then an event sound is played at 8000hz. While > that is playing a music stream starts. According to your scheme we'd > have to open the audio device @ 8khz, then either stay with it (which > case is unnacceptable) or have a big dropout because we need to reinit > the device while music is still playing (which is unnacceptable, too). > > And this is not an artifical example. There are many more like > this. For example, I usually have music playing at CD quality. Then I > start to play a movie at 5.1 and then after a while I notice that I > better switch the music off. In you scheme the movie would continue to > play in 2ch all the time. > > So, I really don't think this will fly. Your rebuttal makes sense. > > That said, when adding codec support in PA I'll also add a module that > will be able to autoswitch profiles based on the streams connecting to > a sink/source/card. This may then be used to implement a scheme like > what you suggest, even though I don't think it makes much sense. > > Lennart > Probably not necessary. When I want to play audio exactly how I want it to play, I tell pulseaudio that the device is *off* to pulseaudio, and use it via alsa. i.e. I have exclusive use of the device during the time I'm using it. When I don't want that any more, I can tell pulseaudio it is available again. If anyone else cares, they can do this too. If they don't care, they can just let the default pulseaudio-alsa make it work.
