[pulseaudio-discuss] [PATCH] fix profile configurations for IEC/SPDIF outputs

[Tanu Kaskinen]

On Mon, 2010-06-21 at 08:58 -0500, pl bossart wrote:
> > I appreciate that the mapping "iec958-surround-40" may be irrelevant
> > seeing as spdif only support stereo PCM, but the I don't really follow
> > the "duplicates what PA could do" bit. Can you explain a bit?
> 
> Surround40 only modifies the channel mapping to generate 4ch.
> PulseAudio could do this natively if the sink was declared with 4ch.

Like Colin, I didn't follow the "duplicates what PA could do" part, and
I don't follow your explanation either. Are you talking about this part
of the patch?

-[Mapping iec958-surround-40]
-device-strings = iec958:%f
-channel-map = front-left,front-right,rear-left,rear-right
-priority = 1

This sippet says that "create a sink/source for the iec958 device with
four channels using this channel map". You say "if the sink was declared
with 4ch". That's exactly what the snippet does - it declares a sink (or
source) with four channels. It doesn't "modify" anything. Now, as Colin
said, that snippet doesn't seem to make any sense, unless spdif actually
supports four-channel PCM streams.

> >> and the former is a lossy codec that will decrease the audio quality
> >> while increasing the workload on your computer. You are probably
> >> better off sending stereo and letting your receiver doing the
> >> post-processing.
> >
> > Hmm, I don't follow here. What if your source is 5.1? Are you saying we
> > should downmix the 5.1 source to stereo and then send the stereo over
> > spdif then let the receiver try and do the best it can with it, e.g. via
> > DPL?
> 
> If your source is 5.1, it came from an encoded AC3/DD file. What you
> want is the passthrough mode. In your configuration, you decode first,
> pass the data to PulseAudio and then reencode. The only case where
> this would make sense is if you wanted to mix your alert tones and
> beeps with the music track, not a compelling use case IMO.

What makes you think AC3 is the only format in the world that can have
5.1 content? And why is mixing other streams not a compelling use case?
Playing an alarm clock sound or a voip app ringtone at the same time
with 5.1 content seems like a valid use case to me.

> > To me that doesn't make sense. I'd rather encode my 5.1 source as DD/AC3
> > and send the whole thing over spdif. But that said, if it's a really bad
> > method of working, then I'd say get the replacement implemented before
> > removing potentially useful bits without any timetable for it's replacement.
> 
> I don't disagree, I just wanted to see which ones made sense and who
> needed those profiles...I really think if this is needed we could
> implement the a52 encoding in PulseAudio and avoid relying on ALSA
> plugins.

I agree about doing the encoding in PulseAudio (AFAIK there may be
patent issues, though). I guess the reason why we currently rely on the
alsa plugin is that doing so doesn't require any work.

> > So how do you propose to send 5.1 streams over spdif without using pure
> > passthough if not via a DD/AC3 encoder of some sort? Are you able to
> > implement DDL or DTS?
> 
> I'll send you a snippet of code to see how to format your ac3 files to
> play them in passthrough mode.

Didn't Coling specifically ask proposals NOT involving passthrough?

Getting back to patching the default profile set file: I think it would
be best to just add a new mapping for AC3 passthrough:

    [Mapping iec958-ac3-passthrough]
    device-strings = iec958:%f
    sample-format = ac3-spdif
    priority = ???
    direction = output

Specifying the channel-map doesn't make much sense, because the same
sink can output any channel configuration that AC3 supports. (Then
there's the question what the resulting sink instance would report when
it's queried for the channel map. I would make the sink channel map
change dynamically depending on what channel configuration the current
stream has.)

The sample-format option isn't currently supported, but it (or some
other similar solution) is needed in order to differentiate between
normal sinks and passthrough sinks in the alsa sink code.

-- 
Tanu Kaskinen