Re: [pulseaudio-discuss] Sink (input) format negotiation concept
On Fri, 19 Aug 2016, at 01:17 PM, Rémi Denis-Courmont wrote: > 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? Right. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Sink (input) format negotiation concept
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. 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). 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. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Sink (input) format negotiation concept
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. Arun may have a better memory than me on this. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
