[pulseaudio-discuss] PulseAudio and AC3 passthrough

[pl bossart]

Wow, someone actually reads my mails...

>> Here's the deal: formatting an AC3 file into the required IEC format
>> takes about 30 lines of code, this can be done in the application that
>> connects to PulseAudio.
>
> Do you plan to do it (the formatting) inside or outside libpulse?

Outside (like in gstreamer/xine)

> Sink inputs would get a new flag: PA_SINK_INPUT_NONPCM. The flag would
> mean that no automatic conversion may be done before passing the stream
> data to the sink, and also that the sink must know what it's doing (=
> understand the non-PCM semantics) if it wants to modify the stream data
> in any way. For example, module-combine doesn't understand any other
> data types than PCM, so module-combine couldn't accept AC3 streams. If
> there was "module-combine-ac3" that would decode the stream, or use
> magic to resample the raw AC3 data, then that would be fine.

Yes the NON_PCM flag is needed.

> Sinks would get a new function: pa_sink_accept_input(pa_sink *s,
> pa_sink_input *si). The function would check whether the sink input is
> suitable for that sink. It would be called inside
> pa_sink_input_may_move_to() and inside pa_sink_input_put(), or if making
> _put() a failable function is not acceptable, then whenever anyone wants
> to call _put(), he must first call _accept_input().

Yes as well. There are some issues though. On most systems,there's a
separate device for digital outputs which isn't loaded by PulseAudio
by default (only loads the first device). My s/pdif output is usable
with hw:0,1 (although using hw:0,0 seems to work for PCM but not
compressed, go figure).

> Sink implementers could provide a callback that would be called inside
> pa_sink_accept_input(). By default inputs with the _NONPCM flag would be
> rejected, but the ALSA sink and module-combine-ac3 would accept also
> _NONPCM inputs if the sample format happened to be PA_SAMPLE_AC3 (for
> ALSA sinks, of course only if the sink's sample format would also be
> PA_SAMPLE_AC3).
>
> So, I'd introduce a new sample format: PA_SAMPLE_AC3.

No for this one. You need to keep the PCM format (frequency, # of
bits) to allow for conversions between bytes/ms.

> Preventing mixing would be achieved by the fact that either sinks only
> accept one AC3 stream at a time, or they don't use pa_sink_render(), but
> do the mixing themselves if they somehow can handle that. I think
> pa_sink_render() should be safe for the ALSA sink to use as long as
> there's only one input and the sample rates match[1]. (I assume AC3
> streams always have six channels. If that's not the case, then there are
> more complications.)

I didn't think of this one. Essentially you rely on the sink to
perform this exclusion. Why not?

> Avoiding applying sw volume could be done by introducing another sink
> input flag: PA_SINK_INPUT_NO_VOLUME and making sure that such sink
> inputs are initialized with PA_VOLUME_NORM. pa_sink_input_set_volume()
> would contain an assertion making sure that it's not called for inputs
> with that flag. That would mean that all the places that call
> pa_sink_input_set_volume() would need to be adapted. The detail that
> even while conceptually the sink input wouldn't have volume,
> initializing the volume to PA_VOLUME_NORM would probably save us from
> touching pa_sink_render() code.

I will have to look into this one. I have no idea what PA_VOLUME_NORM means.

> Similar flag would be needed for sinks too, and similar modifications to
> the places that call pa_sink_set_volume().
>
> I think that covers the most important pieces. The lack of volume would
> need to be communicated to clients somehow (with sink and stream flags
> probably). But old clients wouldn't understand that anyway - when a
> client tries to set the volume of a sink or stream without volume, then
> just make the operation fail, or make the operation a no-op.
>
> [1] Is it a problem that a sink can't reconfigure its sample rate at
> runtime? According to Wikipedia, an AC3 stream's sample rate can be
> either 32 kHz, 44.1 kHz or 48 kHz. It would seem to me that the sink
> should reinitialize its sample rate whenever a new AC3 stream is
> connected to it, otherwise the user can play only those files that have
> the right sample rate.

Yes you need the ability to change frequencies (although in 99% of the
cases it's going to be 48kHz since it works better with video).
But since mixing isn't possible, there's no problem with dynamic
configuration. You can only play one stream at a time, and you can set
the sink frequency to be equal to the stream frequency.

Thanks for again for your feedback, I have to do some work on the
volume part but this was helpful.
- Pierre