[pulseaudio-discuss] Suggestions for enhancement of pulseaudio

[stan]

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.