[pulseaudio-discuss] Sink (input) format negotiation concept
Rémi Denis-Courmont
remi at remlab.net
Fri Aug 19 07:47:03 UTC 2016
Le vendredi 19 août 2016, 12:16:57 Arun Raghavan a écrit :
> On Fri, 19 Aug 2016, at 01:29 AM, Pierre-Louis Bossart wrote:
> > On 8/18/16 11:43 AM, Rémi Denis-Courmont wrote:
> > > Hello,
> > >
> > > For a number of years already, PulseAudio has supported a concept of
> > > sink
> > > inputs with multiple formats. That is meant to support S/PDIF output in
> > > addition to PCM.
> > >
> > > One thing I´m wondering... what is the expected behaviour for an
> > > application to negotiate non-PCM format for a stream? Specifically, if
> > > the application supports IEC 61937, should it always offer the relevant
> > > format (in addition to PCM fallback) when creating the stream? Or
> > > should it do so only if the user has somehow enabled that feature?
> > >
> > > In other words, is PulseAudio supposed to know if IEC 61937 will
> > > actually
> > > work, or is it merely naively listing the formats that the sound card
> > > allows, without regards to adequate speaker presence?
> >
> > The sound card itself only pushes the compressed format on HDMI or
> > SPDIF, it doesn't really know what formats are embedded in the payload.
> > To know what the receiver supports once can read the EDID/ELD
> > information, but this is only for HDMI/DP and not for SPDIF, and it's
> > often corrupted/invalid. If I remember well the solution is to let the
> > user specify what formats work rather than guessing or relying on
> > invalid data.
Well, yeah. That's why I'm asking :)
My question is more, where/how do we expect the user to configure this.
Obviously (sadly) it needs to be configured manually somewhere.
> That's correct. We do not offer these formats on the sink unless the
> user has explicitly signalled that they are available (via options in
> pavucontrol or via pactl on the command line).
So the design assumption is that the user will configure this system-wide (or
rather sink-wide) for all applications?
Then applications should always offer any non-PCM formats that they support?
> The current status is also that the user needs to explicitly switch to a
> digital audio profile if the card also supports an analog profile.
> Having a policy module to automatically select a profile to allow
> matching non-PCM formats might make sense under some circumstances.
--
Rémi Denis-Courmont
http://www.remlab.net/
More information about the pulseaudio-discuss
mailing list