[pulseaudio-discuss] Supporting hardware resampling

[Wade Brown]

heory you'd want to group all the same-freq data together, mix it
>> and then pass it to the sink which would use the DSP to do the
>> resampling needed, which isn't really something supported right now in
>> the PA architecture AFAIK.
>
> With the links you've got to most DSPs you don't actually need to do the
> pre-mixing - the DSP can do the mixing too.

The DSP I have is plenty capable, it could do all the mixing.  The
problem I'm having is I'm still a Pulse Audio module newbie, and from
what I've seen (please PLEASE tell me how to do it right if I'm wrong)
a sink can only advertise one sample rate it accepts, any sink input
connected to it will resample before arriving.  Colin's musing seem to
agree with this too, as he mentions combining identical sample rates.
Luckily muxing is cheap, at least when identical rates are coming in
it's little more than an addition.

>> The trick comes from knowing the h/w can do this. I guess one way of
>> working would be to change things so that each sink can actually open
>> the h/w multiple times for different sample rates if it supports h/w
>> mixing and simply route the audio to the appropriate connection, all the
>> while maintaining a single sink "view" to all things higher up.
>
> For things like the emu10k based cards simply opening the PCM until you
> get an error should do the job here.

Yeah, I can open some obscene amount of PCM paths into the DSP, and my
original goal was to open one per input (and hopefully recycle cleanly
too), but it sounds like I'll have to open one per sample format, mux,
and then pass to the DSP on render for resampling and muxing with
others.

>> It's likely something that will be attached in some way to the UCM work
>> in alsa, so that this kind of thing is only configured when we are told
>> it will work.
>
> This would work for OMAP.  The other thing that Pulse should be able to
> use eventually is Laurent Pinchard's media controller work which will
> allow Pulse to discover the audio routing within the device.  Probably
> that will cover most of the PC cases.

All good future improvements, maybe some day I can take advantage.
For now it looks like I'm left to pioneer some fairly custom solution.
 One module to load (if necessary) a matching sink and route to it,
and one module to actually do the DSP rendering.

Thanks for the discussions so far guys!

-- 
Wade