On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote:
> First this passthrough mode is only valid for S/PDIF and HDMI outputs.
> In both cases, the receiver may or may not support encoded content,
> and in the SPDIF case you have no way of querying what the receiver
> capabilities are. You absolutely do not want to send passthrough
> streams without making sure the configuration makes sense.
> So somehow user interaction is required to explicitly tell PulseAudio
> the receiver supports AC3/DTS passthrough. To be more self-explanatory
> we should have a check-box in pavucontrol than a different profile.
> I really did not want to switch configurations depending on the type
> of content, ALSA/iec958 accepts both.

I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.

Having thought this for a while, the only thing that really irritates me
in your design is that the semantics of the PA_SINK_PASSTHROUGH become
messy: the flag says that "in addition to normal PCM streams, this sink
supports also passthrough streams, except at times when there already
exist PCM streams, and btw, while a passthrough stream is playing, PCM
streams cease to be supported". I guess that's not a very practical
problem, though.

Ah, but now a better argument popped into my mind. If a sink can enter
the passthrough mode on the fly, then that has a consequence that
affects any application that is interested in sink volumes: whether a
sink has adjustable volume can change any time. That's not very nice.

> > Previously I claimed that since the the stream is compressed, we
> > inevitably will have to extend the code in pa_bytes_to_usec(), but I
> > realized now that as long as we pretend that the stream really is a
> > regular stereo stream, all calculations end up correct. Now the only
> > problem is that the user is given sort of wrong information, but I don't
> > think that's a big problem, so I agree with your approach of leaving the
> > sample spec alone and relying only on the sink and sink input flags. The
> > code can be improved later, if needed.
>
>
> > About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> > First, "non-audio" is not really correct, because the data is still
> > audio, but the main issue is the "iec958" part. There can potentially be
> > many formats that need to be passed through unchanged, so in the future
> > there could be need for PA_STREAM_NONAUDIO_FOO and
> > PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> > the format information - the format should have its own variable. Until
> > new formats are introduced, you can still rely on a single flag, though.
> > I propose that you just rename the flags:
> >
> > - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
> > - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
> > - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.
>
> I really don't think there are that many formats. The only use cases I
> can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
> audio. Adding flags on the sinks is no big deal.

Even if we have only two formats, iec958 and mp3, I don't see why the
sink flags would the proper place to specify the format. I believe most
of the passthrough related code is only interested in the fact that the
stream data shall not be touched. If there are multiple flags for all
the different passthrough formats, then all that code will have to check
for two flags instead of one.

> The real problem is at the pa_stream level. We don't want to have to
> extend the protocol several times. I added a flag but if we have more
> than one format we will need more room for subtypes. We should
> probably extend the buff_attr attributes for this?

I haven't though about this much, but I have a feeling that more complex
formats (like mp3) are going to need more metadata than currently
available (stuff like bitrate, CBR vs VBR etc.), and if support for
other codecs is going to be needed in the future, the set of metadata
items might vary between codecs. I wouldn't care about all that complex
stuff before it's implemented - in other words, I don't see it as a big
problem if the protocol will have to be extended multiple times for
different codecs. (Of course it would be nice to avoid that, but I
wouldn't trust at least myself to get it right at first try without
actually implementing the mp3 passthrough functionality at the same
time.)

> > I think the most natural place for input compatibility checking is in
> > the sink object. At least it achieves better encapsulation, because then
> > you don't need to poke the sink's "private-ish" data from outside the
> > sink object. That makes future changes easier to do.
>
> I disagree. I think you want a common logic in the core to make sure
> that things work the same way no matter what configuration you use.
> And its make sure we don't have to modify all existing sinks to
> perform the same checks.

There would of course be a standard implementation for sinks that don't
do any "strange" stuff. I thought individual sink implementations could
choose to amend the standard logic, but actually I'm not sure how it
could be done without duplicating code.

Giving it a second thought, the "can this sink input be connected to
this sink" question can be thought equally well as a method of sinks or
sink inputs, or even as a plain old independent function. So, doing it
like you do it in your patch is fine by me (just don't use "iec958"
where the logic isn't really bound to the exact format).

> > The NOVOLUME flags can be exported to clients, so they can choose to not
> > show any volume controls. Legacy clients should get the
> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> > sinks that have the NOVOLUME flag.
>
> Yes the volume needs more work. I don't really understand all this
> code through, so for now I disabled the set-volume() routines without
> notifying the client. You end-up in the situation where pavucontrol
> can change the volume but nothing happens, this is not user-friendly.
> Is this NOVOLUME flag an existing one, or something that would need to be added?

It needs to be added.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote:
> First this passthrough mode is only valid for S/PDIF and HDMI outputs.
> In both cases, the receiver may or may not support encoded content,
> and in the SPDIF case you have no way of querying what the receiver
> capabilities are. You absolutely do not want to send passthrough
> streams without making sure the configuration makes sense.
> So somehow user interaction is required to explicitly tell PulseAudio
> the receiver supports AC3/DTS passthrough. To be more self-explanatory
> we should have a check-box in pavucontrol than a different profile.
> I really did not want to switch configurations depending on the type
> of content, ALSA/iec958 accepts both.

I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.

Having thought this for a while, the only thing that really irritates me
in your design is that the semantics of the PA_SINK_PASSTHROUGH become
messy: the flag says that "in addition to normal PCM streams, this sink
supports also passthrough streams, except at times when there already
exist PCM streams, and btw, while a passthrough stream is playing, PCM
streams cease to be supported". I guess that's not a very practical
problem, though.

Ah, but now a better argument popped into my mind. If a sink can enter
the passthrough mode on the fly, then that has a consequence that
affects any application that is interested in sink volumes: whether a
sink has adjustable volume can change any time. That's not very nice.

> > Previously I claimed that since the the stream is compressed, we
> > inevitably will have to extend the code in pa_bytes_to_usec(), but I
> > realized now that as long as we pretend that the stream really is a
> > regular stereo stream, all calculations end up correct. Now the only
> > problem is that the user is given sort of wrong information, but I don't
> > think that's a big problem, so I agree with your approach of leaving the
> > sample spec alone and relying only on the sink and sink input flags. The
> > code can be improved later, if needed.
>
>
> > About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> > First, "non-audio" is not really correct, because the data is still
> > audio, but the main issue is the "iec958" part. There can potentially be
> > many formats that need to be passed through unchanged, so in the future
> > there could be need for PA_STREAM_NONAUDIO_FOO and
> > PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> > the format information - the format should have its own variable. Until
> > new formats are introduced, you can still rely on a single flag, though.
> > I propose that you just rename the flags:
> >
> > - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
> > - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
> > - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.
>
> I really don't think there are that many formats. The only use cases I
> can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
> audio. Adding flags on the sinks is no big deal.

Even if we have only two formats, iec958 and mp3, I don't see why the
sink flags would the proper place to specify the format. I believe most
of the passthrough related code is only interested in the fact that the
stream data shall not be touched. If there are multiple flags for all
the different passthrough formats, then all that code will have to check
for two flags instead of one.

> The real problem is at the pa_stream level. We don't want to have to
> extend the protocol several times. I added a flag but if we have more
> than one format we will need more room for subtypes. We should
> probably extend the buff_attr attributes for this?

I haven't though about this much, but I have a feeling that more complex
formats (like mp3) are going to need more metadata than currently
available (stuff like bitrate, CBR vs VBR etc.), and if support for
other codecs is going to be needed in the future, the set of metadata
items might vary between codecs. I wouldn't care about all that complex
stuff before it's implemented - in other words, I don't see it as a big
problem if the protocol will have to be extended multiple times for
different codecs. (Of course it would be nice to avoid that, but I
wouldn't trust at least myself to get it right at first try without
actually implementing the mp3 passthrough functionality at the same
time.)

> > I think the most natural place for input compatibility checking is in
> > the sink object. At least it achieves better encapsulation, because then
> > you don't need to poke the sink's "private-ish" data from outside the
> > sink object. That makes future changes easier to do.
>
> I disagree. I think you want a common logic in the core to make sure
> that things work the same way no matter what configuration you use.
> And its make sure we don't have to modify all existing sinks to
> perform the same checks.

There would of course be a standard implementation for sinks that don't
do any "strange" stuff. I thought individual sink implementations could
choose to amend the standard logic, but actually I'm not sure how it
could be done without duplicating code.

Giving it a second thought, the "can this sink input be connected to
this sink" question can be thought equally well as a method of sinks or
sink inputs, or even as a plain old independent function. So, doing it
like you do it in your patch is fine by me (just don't use "iec958"
where the logic isn't really bound to the exact format).

> > The NOVOLUME flags can be exported to clients, so they can choose to not
> > show any volume controls. Legacy clients should get the
> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> > sinks that have the NOVOLUME flag.
>
> Yes the volume needs more work. I don't really understand all this
> code through, so for now I disabled the set-volume() routines without
> notifying the client. You end-up in the situation where pavucontrol
> can change the volume but nothing happens, this is not user-friendly.
> Is this NOVOLUME flag an existing one, or something that would need to be added?

It needs to be added.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I agree that it's not really a good solution to require the user to
> change the card profile manually to enable passthrough via spdif. But as
> I said, a separate module could take care switching between the profiles
> as needed.

I don't understand your proposal. What do you mean by separate
'module' and how would this work with the current mixer profiles?

> Having thought this for a while, the only thing that really irritates me
> in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> messy: the flag says that "in addition to normal PCM streams, this sink
> supports also passthrough streams, except at times when there already
> exist PCM streams, and btw, while a passthrough stream is playing, PCM
> streams cease to be supported". I guess that's not a very practical
> problem, though.

It's not really my design, it's just how SPDIF/HDMI work...

> Ah, but now a better argument popped into my mind. If a sink can enter
> the passthrough mode on the fly, then that has a consequence that
> affects any application that is interested in sink volumes: whether a
> sink has adjustable volume can change any time. That's not very nice.

Duh? If we fixed the volume stuff so that that the volume control app
disables its sliders when passthrough AC3 is enabled, what would be
the issue. This is how VLC works, when you stream AC3 data the volume
control is no longer enabled.

> Even if we have only two formats, iec958 and mp3, I don't see why the
> sink flags would the proper place to specify the format. I believe most
> of the passthrough related code is only interested in the fact that the
> stream data shall not be touched. If there are multiple flags for all
> the different passthrough formats, then all that code will have to check
> for two flags instead of one.

I guess we could have a two-step process, where you first detect if
the sink and sink-input have support for PASSTHROUGH, and then in a
second step you verify that the 'subtype' (iec958 or mp3) is
compatible. The logic for rejecting connections is the same... You
only need one last step to make sure types are compatible.

> There would of course be a standard implementation for sinks that don't
> do any "strange" stuff. I thought individual sink implementations could
> choose to amend the standard logic, but actually I'm not sure how it
> could be done without duplicating code.
>
> Giving it a second thought, the "can this sink input be connected to
> this sink" question can be thought equally well as a method of sinks or
> sink inputs, or even as a plain old independent function. So, doing it
> like you do it in your patch is fine by me (just don't use "iec958"
> where the logic isn't really bound to the exact format).

As I said above, we can have a first pass implemented in the core that
checks things are fine, then a second pass implemented by sinks who
support passthrough mode to check fine-grained compatibility.

>> > The NOVOLUME flags can be exported to clients, so they can choose to not
>> > show any volume controls. Legacy clients should get the
>> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
>> > sinks that have the NOVOLUME flag.
>>
>> Yes the volume needs more work. I don't really understand all this
>> code through, so for now I disabled the set-volume() routines without
>> notifying the client. You end-up in the situation where pavucontrol
>> can change the volume but nothing happens, this is not user-friendly.
>> Is this NOVOLUME flag an existing one, or something that would need to be added?
>
> It needs to be added.

There's already a detection in the mixer code that the hw_volume is
available or not. Maybe we can use this as well.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote:
> First this passthrough mode is only valid for S/PDIF and HDMI outputs.
> In both cases, the receiver may or may not support encoded content,
> and in the SPDIF case you have no way of querying what the receiver
> capabilities are. You absolutely do not want to send passthrough
> streams without making sure the configuration makes sense.
> So somehow user interaction is required to explicitly tell PulseAudio
> the receiver supports AC3/DTS passthrough. To be more self-explanatory
> we should have a check-box in pavucontrol than a different profile.
> I really did not want to switch configurations depending on the type
> of content, ALSA/iec958 accepts both.

I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.

Having thought this for a while, the only thing that really irritates me
in your design is that the semantics of the PA_SINK_PASSTHROUGH become
messy: the flag says that "in addition to normal PCM streams, this sink
supports also passthrough streams, except at times when there already
exist PCM streams, and btw, while a passthrough stream is playing, PCM
streams cease to be supported". I guess that's not a very practical
problem, though.

Ah, but now a better argument popped into my mind. If a sink can enter
the passthrough mode on the fly, then that has a consequence that
affects any application that is interested in sink volumes: whether a
sink has adjustable volume can change any time. That's not very nice.

> > Previously I claimed that since the the stream is compressed, we
> > inevitably will have to extend the code in pa_bytes_to_usec(), but I
> > realized now that as long as we pretend that the stream really is a
> > regular stereo stream, all calculations end up correct. Now the only
> > problem is that the user is given sort of wrong information, but I don't
> > think that's a big problem, so I agree with your approach of leaving the
> > sample spec alone and relying only on the sink and sink input flags. The
> > code can be improved later, if needed.
>
>
> > About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> > First, "non-audio" is not really correct, because the data is still
> > audio, but the main issue is the "iec958" part. There can potentially be
> > many formats that need to be passed through unchanged, so in the future
> > there could be need for PA_STREAM_NONAUDIO_FOO and
> > PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> > the format information - the format should have its own variable. Until
> > new formats are introduced, you can still rely on a single flag, though.
> > I propose that you just rename the flags:
> >
> > - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
> > - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
> > - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.
>
> I really don't think there are that many formats. The only use cases I
> can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
> audio. Adding flags on the sinks is no big deal.

Even if we have only two formats, iec958 and mp3, I don't see why the
sink flags would the proper place to specify the format. I believe most
of the passthrough related code is only interested in the fact that the
stream data shall not be touched. If there are multiple flags for all
the different passthrough formats, then all that code will have to check
for two flags instead of one.

> The real problem is at the pa_stream level. We don't want to have to
> extend the protocol several times. I added a flag but if we have more
> than one format we will need more room for subtypes. We should
> probably extend the buff_attr attributes for this?

I haven't though about this much, but I have a feeling that more complex
formats (like mp3) are going to need more metadata than currently
available (stuff like bitrate, CBR vs VBR etc.), and if support for
other codecs is going to be needed in the future, the set of metadata
items might vary between codecs. I wouldn't care about all that complex
stuff before it's implemented - in other words, I don't see it as a big
problem if the protocol will have to be extended multiple times for
different codecs. (Of course it would be nice to avoid that, but I
wouldn't trust at least myself to get it right at first try without
actually implementing the mp3 passthrough functionality at the same
time.)

> > I think the most natural place for input compatibility checking is in
> > the sink object. At least it achieves better encapsulation, because then
> > you don't need to poke the sink's "private-ish" data from outside the
> > sink object. That makes future changes easier to do.
>
> I disagree. I think you want a common logic in the core to make sure
> that things work the same way no matter what configuration you use.
> And its make sure we don't have to modify all existing sinks to
> perform the same checks.

There would of course be a standard implementation for sinks that don't
do any "strange" stuff. I thought individual sink implementations could
choose to amend the standard logic, but actually I'm not sure how it
could be done without duplicating code.

Giving it a second thought, the "can this sink input be connected to
this sink" question can be thought equally well as a method of sinks or
sink inputs, or even as a plain old independent function. So, doing it
like you do it in your patch is fine by me (just don't use "iec958"
where the logic isn't really bound to the exact format).

> > The NOVOLUME flags can be exported to clients, so they can choose to not
> > show any volume controls. Legacy clients should get the
> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> > sinks that have the NOVOLUME flag.
>
> Yes the volume needs more work. I don't really understand all this
> code through, so for now I disabled the set-volume() routines without
> notifying the client. You end-up in the situation where pavucontrol
> can change the volume but nothing happens, this is not user-friendly.
> Is this NOVOLUME flag an existing one, or something that would need to be added?

It needs to be added.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I agree that it's not really a good solution to require the user to
> change the card profile manually to enable passthrough via spdif. But as
> I said, a separate module could take care switching between the profiles
> as needed.

I don't understand your proposal. What do you mean by separate
'module' and how would this work with the current mixer profiles?

> Having thought this for a while, the only thing that really irritates me
> in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> messy: the flag says that "in addition to normal PCM streams, this sink
> supports also passthrough streams, except at times when there already
> exist PCM streams, and btw, while a passthrough stream is playing, PCM
> streams cease to be supported". I guess that's not a very practical
> problem, though.

It's not really my design, it's just how SPDIF/HDMI work...

> Ah, but now a better argument popped into my mind. If a sink can enter
> the passthrough mode on the fly, then that has a consequence that
> affects any application that is interested in sink volumes: whether a
> sink has adjustable volume can change any time. That's not very nice.

Duh? If we fixed the volume stuff so that that the volume control app
disables its sliders when passthrough AC3 is enabled, what would be
the issue. This is how VLC works, when you stream AC3 data the volume
control is no longer enabled.

> Even if we have only two formats, iec958 and mp3, I don't see why the
> sink flags would the proper place to specify the format. I believe most
> of the passthrough related code is only interested in the fact that the
> stream data shall not be touched. If there are multiple flags for all
> the different passthrough formats, then all that code will have to check
> for two flags instead of one.

I guess we could have a two-step process, where you first detect if
the sink and sink-input have support for PASSTHROUGH, and then in a
second step you verify that the 'subtype' (iec958 or mp3) is
compatible. The logic for rejecting connections is the same... You
only need one last step to make sure types are compatible.

> There would of course be a standard implementation for sinks that don't
> do any "strange" stuff. I thought individual sink implementations could
> choose to amend the standard logic, but actually I'm not sure how it
> could be done without duplicating code.
>
> Giving it a second thought, the "can this sink input be connected to
> this sink" question can be thought equally well as a method of sinks or
> sink inputs, or even as a plain old independent function. So, doing it
> like you do it in your patch is fine by me (just don't use "iec958"
> where the logic isn't really bound to the exact format).

As I said above, we can have a first pass implemented in the core that
checks things are fine, then a second pass implemented by sinks who
support passthrough mode to check fine-grained compatibility.

>> > The NOVOLUME flags can be exported to clients, so they can choose to not
>> > show any volume controls. Legacy clients should get the
>> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
>> > sinks that have the NOVOLUME flag.
>>
>> Yes the volume needs more work. I don't really understand all this
>> code through, so for now I disabled the set-volume() routines without
>> notifying the client. You end-up in the situation where pavucontrol
>> can change the volume but nothing happens, this is not user-friendly.
>> Is this NOVOLUME flag an existing one, or something that would need to be added?
>
> It needs to be added.

There's already a detection in the mixer code that the hw_volume is
available or not. Maybe we can use this as well.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or
is someone actively looking at developing it?
2. I think that encoding needs to be considered as part of the design ie. the
possibility of AC3 or MP3 encoding before output to SPDIF.

Perhaps you're already past this point, but there is an Alsa utility iecset
which returns (and can set) whether raw data or PCM is being passed to SPDIF. So
presumably the Pulseaudio passthrough for Alsa just needs to call the same
function that utility does.

Can someone point me to any design and API docs for Pulseaudio as I'm interested
in learning where and how it connects to Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote:
> First this passthrough mode is only valid for S/PDIF and HDMI outputs.
> In both cases, the receiver may or may not support encoded content,
> and in the SPDIF case you have no way of querying what the receiver
> capabilities are. You absolutely do not want to send passthrough
> streams without making sure the configuration makes sense.
> So somehow user interaction is required to explicitly tell PulseAudio
> the receiver supports AC3/DTS passthrough. To be more self-explanatory
> we should have a check-box in pavucontrol than a different profile.
> I really did not want to switch configurations depending on the type
> of content, ALSA/iec958 accepts both.

I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.

Having thought this for a while, the only thing that really irritates me
in your design is that the semantics of the PA_SINK_PASSTHROUGH become
messy: the flag says that "in addition to normal PCM streams, this sink
supports also passthrough streams, except at times when there already
exist PCM streams, and btw, while a passthrough stream is playing, PCM
streams cease to be supported". I guess that's not a very practical
problem, though.

Ah, but now a better argument popped into my mind. If a sink can enter
the passthrough mode on the fly, then that has a consequence that
affects any application that is interested in sink volumes: whether a
sink has adjustable volume can change any time. That's not very nice.

> > Previously I claimed that since the the stream is compressed, we
> > inevitably will have to extend the code in pa_bytes_to_usec(), but I
> > realized now that as long as we pretend that the stream really is a
> > regular stereo stream, all calculations end up correct. Now the only
> > problem is that the user is given sort of wrong information, but I don't
> > think that's a big problem, so I agree with your approach of leaving the
> > sample spec alone and relying only on the sink and sink input flags. The
> > code can be improved later, if needed.
>
>
> > About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> > First, "non-audio" is not really correct, because the data is still
> > audio, but the main issue is the "iec958" part. There can potentially be
> > many formats that need to be passed through unchanged, so in the future
> > there could be need for PA_STREAM_NONAUDIO_FOO and
> > PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> > the format information - the format should have its own variable. Until
> > new formats are introduced, you can still rely on a single flag, though.
> > I propose that you just rename the flags:
> >
> > - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
> > - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
> > - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.
>
> I really don't think there are that many formats. The only use cases I
> can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
> audio. Adding flags on the sinks is no big deal.

Even if we have only two formats, iec958 and mp3, I don't see why the
sink flags would the proper place to specify the format. I believe most
of the passthrough related code is only interested in the fact that the
stream data shall not be touched. If there are multiple flags for all
the different passthrough formats, then all that code will have to check
for two flags instead of one.

> The real problem is at the pa_stream level. We don't want to have to
> extend the protocol several times. I added a flag but if we have more
> than one format we will need more room for subtypes. We should
> probably extend the buff_attr attributes for this?

I haven't though about this much, but I have a feeling that more complex
formats (like mp3) are going to need more metadata than currently
available (stuff like bitrate, CBR vs VBR etc.), and if support for
other codecs is going to be needed in the future, the set of metadata
items might vary between codecs. I wouldn't care about all that complex
stuff before it's implemented - in other words, I don't see it as a big
problem if the protocol will have to be extended multiple times for
different codecs. (Of course it would be nice to avoid that, but I
wouldn't trust at least myself to get it right at first try without
actually implementing the mp3 passthrough functionality at the same
time.)

> > I think the most natural place for input compatibility checking is in
> > the sink object. At least it achieves better encapsulation, because then
> > you don't need to poke the sink's "private-ish" data from outside the
> > sink object. That makes future changes easier to do.
>
> I disagree. I think you want a common logic in the core to make sure
> that things work the same way no matter what configuration you use.
> And its make sure we don't have to modify all existing sinks to
> perform the same checks.

There would of course be a standard implementation for sinks that don't
do any "strange" stuff. I thought individual sink implementations could
choose to amend the standard logic, but actually I'm not sure how it
could be done without duplicating code.

Giving it a second thought, the "can this sink input be connected to
this sink" question can be thought equally well as a method of sinks or
sink inputs, or even as a plain old independent function. So, doing it
like you do it in your patch is fine by me (just don't use "iec958"
where the logic isn't really bound to the exact format).

> > The NOVOLUME flags can be exported to clients, so they can choose to not
> > show any volume controls. Legacy clients should get the
> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> > sinks that have the NOVOLUME flag.
>
> Yes the volume needs more work. I don't really understand all this
> code through, so for now I disabled the set-volume() routines without
> notifying the client. You end-up in the situation where pavucontrol
> can change the volume but nothing happens, this is not user-friendly.
> Is this NOVOLUME flag an existing one, or something that would need to be added?

It needs to be added.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I agree that it's not really a good solution to require the user to
> change the card profile manually to enable passthrough via spdif. But as
> I said, a separate module could take care switching between the profiles
> as needed.

I don't understand your proposal. What do you mean by separate
'module' and how would this work with the current mixer profiles?

> Having thought this for a while, the only thing that really irritates me
> in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> messy: the flag says that "in addition to normal PCM streams, this sink
> supports also passthrough streams, except at times when there already
> exist PCM streams, and btw, while a passthrough stream is playing, PCM
> streams cease to be supported". I guess that's not a very practical
> problem, though.

It's not really my design, it's just how SPDIF/HDMI work...

> Ah, but now a better argument popped into my mind. If a sink can enter
> the passthrough mode on the fly, then that has a consequence that
> affects any application that is interested in sink volumes: whether a
> sink has adjustable volume can change any time. That's not very nice.

Duh? If we fixed the volume stuff so that that the volume control app
disables its sliders when passthrough AC3 is enabled, what would be
the issue. This is how VLC works, when you stream AC3 data the volume
control is no longer enabled.

> Even if we have only two formats, iec958 and mp3, I don't see why the
> sink flags would the proper place to specify the format. I believe most
> of the passthrough related code is only interested in the fact that the
> stream data shall not be touched. If there are multiple flags for all
> the different passthrough formats, then all that code will have to check
> for two flags instead of one.

I guess we could have a two-step process, where you first detect if
the sink and sink-input have support for PASSTHROUGH, and then in a
second step you verify that the 'subtype' (iec958 or mp3) is
compatible. The logic for rejecting connections is the same... You
only need one last step to make sure types are compatible.

> There would of course be a standard implementation for sinks that don't
> do any "strange" stuff. I thought individual sink implementations could
> choose to amend the standard logic, but actually I'm not sure how it
> could be done without duplicating code.
>
> Giving it a second thought, the "can this sink input be connected to
> this sink" question can be thought equally well as a method of sinks or
> sink inputs, or even as a plain old independent function. So, doing it
> like you do it in your patch is fine by me (just don't use "iec958"
> where the logic isn't really bound to the exact format).

As I said above, we can have a first pass implemented in the core that
checks things are fine, then a second pass implemented by sinks who
support passthrough mode to check fine-grained compatibility.

>> > The NOVOLUME flags can be exported to clients, so they can choose to not
>> > show any volume controls. Legacy clients should get the
>> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
>> > sinks that have the NOVOLUME flag.
>>
>> Yes the volume needs more work. I don't really understand all this
>> code through, so for now I disabled the set-volume() routines without
>> notifying the client. You end-up in the situation where pavucontrol
>> can change the volume but nothing happens, this is not user-friendly.
>> Is this NOVOLUME flag an existing one, or something that would need to be added?
>
> It needs to be added.

There's already a detection in the mixer code that the hw_volume is
available or not. Maybe we can use this as well.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or
is someone actively looking at developing it?
2. I think that encoding needs to be considered as part of the design ie. the
possibility of AC3 or MP3 encoding before output to SPDIF.

Perhaps you're already past this point, but there is an Alsa utility iecset
which returns (and can set) whether raw data or PCM is being passed to SPDIF. So
presumably the Pulseaudio passthrough for Alsa just needs to call the same
function that utility does.

Can someone point me to any design and API docs for Pulseaudio as I'm interested
in learning where and how it connects to Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > 1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point
> only or is someone actively looking at developing it?

AC3 passthrough works (see patches at start of thread). That said
there are still some opens and feedback is still welcome. I guess this
will be part of Meego at some point, but since there''s nothing hw
specific the discussion takes place in the open.

> 2. I think that encoding needs to be considered as part of the design ie.
> the possibility of AC3 or MP3 encoding before output to SPDIF.

AC3 encoding can be done by selecting the relevant profile
(ac3-iec958). The encoding takes place in alsa-lib a52 plugin. I
initially removed these profiles but took some flak for it, apparently
some people encode their multichannel streams prior to SPDIF
transmission.
I am afraid MP3 encoding in PulseAudio doesn't make sense, not
supported either by SPDIF or HDMI. And for BT use cases, you might as
well encode in SBC if you have PCM in the first place.

> Perhaps you're already past this point, but there is an Alsa utility iecset
> which returns (and can set) whether raw data or PCM is being passed to
> SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call
> the same function that utility does.

iecset sets the AES0-3 bytes, but does not handle actual data
formatting which is done by the gstreamer ac3iec958 element and by the
alsa-lib iec958 plugin. For now I don't even bother to set these bits,
they are so unreliable that receivers usually ignore them.

> Can someone point me to any design and API docs for Pulseaudio as I'm
> interested in learning where and how it connects to Alsa?

No real docs. See the code in src/modules/alsa. Only took me a year to
figure things out :-(
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote:
> First this passthrough mode is only valid for S/PDIF and HDMI outputs.
> In both cases, the receiver may or may not support encoded content,
> and in the SPDIF case you have no way of querying what the receiver
> capabilities are. You absolutely do not want to send passthrough
> streams without making sure the configuration makes sense.
> So somehow user interaction is required to explicitly tell PulseAudio
> the receiver supports AC3/DTS passthrough. To be more self-explanatory
> we should have a check-box in pavucontrol than a different profile.
> I really did not want to switch configurations depending on the type
> of content, ALSA/iec958 accepts both.

I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.

Having thought this for a while, the only thing that really irritates me
in your design is that the semantics of the PA_SINK_PASSTHROUGH become
messy: the flag says that "in addition to normal PCM streams, this sink
supports also passthrough streams, except at times when there already
exist PCM streams, and btw, while a passthrough stream is playing, PCM
streams cease to be supported". I guess that's not a very practical
problem, though.

Ah, but now a better argument popped into my mind. If a sink can enter
the passthrough mode on the fly, then that has a consequence that
affects any application that is interested in sink volumes: whether a
sink has adjustable volume can change any time. That's not very nice.

> > Previously I claimed that since the the stream is compressed, we
> > inevitably will have to extend the code in pa_bytes_to_usec(), but I
> > realized now that as long as we pretend that the stream really is a
> > regular stereo stream, all calculations end up correct. Now the only
> > problem is that the user is given sort of wrong information, but I don't
> > think that's a big problem, so I agree with your approach of leaving the
> > sample spec alone and relying only on the sink and sink input flags. The
> > code can be improved later, if needed.
>
>
> > About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> > First, "non-audio" is not really correct, because the data is still
> > audio, but the main issue is the "iec958" part. There can potentially be
> > many formats that need to be passed through unchanged, so in the future
> > there could be need for PA_STREAM_NONAUDIO_FOO and
> > PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> > the format information - the format should have its own variable. Until
> > new formats are introduced, you can still rely on a single flag, though.
> > I propose that you just rename the flags:
> >
> > - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
> > - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
> > - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.
>
> I really don't think there are that many formats. The only use cases I
> can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
> audio. Adding flags on the sinks is no big deal.

Even if we have only two formats, iec958 and mp3, I don't see why the
sink flags would the proper place to specify the format. I believe most
of the passthrough related code is only interested in the fact that the
stream data shall not be touched. If there are multiple flags for all
the different passthrough formats, then all that code will have to check
for two flags instead of one.

> The real problem is at the pa_stream level. We don't want to have to
> extend the protocol several times. I added a flag but if we have more
> than one format we will need more room for subtypes. We should
> probably extend the buff_attr attributes for this?

I haven't though about this much, but I have a feeling that more complex
formats (like mp3) are going to need more metadata than currently
available (stuff like bitrate, CBR vs VBR etc.), and if support for
other codecs is going to be needed in the future, the set of metadata
items might vary between codecs. I wouldn't care about all that complex
stuff before it's implemented - in other words, I don't see it as a big
problem if the protocol will have to be extended multiple times for
different codecs. (Of course it would be nice to avoid that, but I
wouldn't trust at least myself to get it right at first try without
actually implementing the mp3 passthrough functionality at the same
time.)

> > I think the most natural place for input compatibility checking is in
> > the sink object. At least it achieves better encapsulation, because then
> > you don't need to poke the sink's "private-ish" data from outside the
> > sink object. That makes future changes easier to do.
>
> I disagree. I think you want a common logic in the core to make sure
> that things work the same way no matter what configuration you use.
> And its make sure we don't have to modify all existing sinks to
> perform the same checks.

There would of course be a standard implementation for sinks that don't
do any "strange" stuff. I thought individual sink implementations could
choose to amend the standard logic, but actually I'm not sure how it
could be done without duplicating code.

Giving it a second thought, the "can this sink input be connected to
this sink" question can be thought equally well as a method of sinks or
sink inputs, or even as a plain old independent function. So, doing it
like you do it in your patch is fine by me (just don't use "iec958"
where the logic isn't really bound to the exact format).

> > The NOVOLUME flags can be exported to clients, so they can choose to not
> > show any volume controls. Legacy clients should get the
> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> > sinks that have the NOVOLUME flag.
>
> Yes the volume needs more work. I don't really understand all this
> code through, so for now I disabled the set-volume() routines without
> notifying the client. You end-up in the situation where pavucontrol
> can change the volume but nothing happens, this is not user-friendly.
> Is this NOVOLUME flag an existing one, or something that would need to be added?

It needs to be added.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I agree that it's not really a good solution to require the user to
> change the card profile manually to enable passthrough via spdif. But as
> I said, a separate module could take care switching between the profiles
> as needed.

I don't understand your proposal. What do you mean by separate
'module' and how would this work with the current mixer profiles?

> Having thought this for a while, the only thing that really irritates me
> in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> messy: the flag says that "in addition to normal PCM streams, this sink
> supports also passthrough streams, except at times when there already
> exist PCM streams, and btw, while a passthrough stream is playing, PCM
> streams cease to be supported". I guess that's not a very practical
> problem, though.

It's not really my design, it's just how SPDIF/HDMI work...

> Ah, but now a better argument popped into my mind. If a sink can enter
> the passthrough mode on the fly, then that has a consequence that
> affects any application that is interested in sink volumes: whether a
> sink has adjustable volume can change any time. That's not very nice.

Duh? If we fixed the volume stuff so that that the volume control app
disables its sliders when passthrough AC3 is enabled, what would be
the issue. This is how VLC works, when you stream AC3 data the volume
control is no longer enabled.

> Even if we have only two formats, iec958 and mp3, I don't see why the
> sink flags would the proper place to specify the format. I believe most
> of the passthrough related code is only interested in the fact that the
> stream data shall not be touched. If there are multiple flags for all
> the different passthrough formats, then all that code will have to check
> for two flags instead of one.

I guess we could have a two-step process, where you first detect if
the sink and sink-input have support for PASSTHROUGH, and then in a
second step you verify that the 'subtype' (iec958 or mp3) is
compatible. The logic for rejecting connections is the same... You
only need one last step to make sure types are compatible.

> There would of course be a standard implementation for sinks that don't
> do any "strange" stuff. I thought individual sink implementations could
> choose to amend the standard logic, but actually I'm not sure how it
> could be done without duplicating code.
>
> Giving it a second thought, the "can this sink input be connected to
> this sink" question can be thought equally well as a method of sinks or
> sink inputs, or even as a plain old independent function. So, doing it
> like you do it in your patch is fine by me (just don't use "iec958"
> where the logic isn't really bound to the exact format).

As I said above, we can have a first pass implemented in the core that
checks things are fine, then a second pass implemented by sinks who
support passthrough mode to check fine-grained compatibility.

>> > The NOVOLUME flags can be exported to clients, so they can choose to not
>> > show any volume controls. Legacy clients should get the
>> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
>> > sinks that have the NOVOLUME flag.
>>
>> Yes the volume needs more work. I don't really understand all this
>> code through, so for now I disabled the set-volume() routines without
>> notifying the client. You end-up in the situation where pavucontrol
>> can change the volume but nothing happens, this is not user-friendly.
>> Is this NOVOLUME flag an existing one, or something that would need to be added?
>
> It needs to be added.

There's already a detection in the mixer code that the hw_volume is
available or not. Maybe we can use this as well.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or
is someone actively looking at developing it?
2. I think that encoding needs to be considered as part of the design ie. the
possibility of AC3 or MP3 encoding before output to SPDIF.

Perhaps you're already past this point, but there is an Alsa utility iecset
which returns (and can set) whether raw data or PCM is being passed to SPDIF. So
presumably the Pulseaudio passthrough for Alsa just needs to call the same
function that utility does.

Can someone point me to any design and API docs for Pulseaudio as I'm interested
in learning where and how it connects to Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > 1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point
> only or is someone actively looking at developing it?

AC3 passthrough works (see patches at start of thread). That said
there are still some opens and feedback is still welcome. I guess this
will be part of Meego at some point, but since there''s nothing hw
specific the discussion takes place in the open.

> 2. I think that encoding needs to be considered as part of the design ie.
> the possibility of AC3 or MP3 encoding before output to SPDIF.

AC3 encoding can be done by selecting the relevant profile
(ac3-iec958). The encoding takes place in alsa-lib a52 plugin. I
initially removed these profiles but took some flak for it, apparently
some people encode their multichannel streams prior to SPDIF
transmission.
I am afraid MP3 encoding in PulseAudio doesn't make sense, not
supported either by SPDIF or HDMI. And for BT use cases, you might as
well encode in SBC if you have PCM in the first place.

> Perhaps you're already past this point, but there is an Alsa utility iecset
> which returns (and can set) whether raw data or PCM is being passed to
> SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call
> the same function that utility does.

iecset sets the AES0-3 bytes, but does not handle actual data
formatting which is done by the gstreamer ac3iec958 element and by the
alsa-lib iec958 plugin. For now I don't even bother to set these bits,
they are so unreliable that receivers usually ignore them.

> Can someone point me to any design and API docs for Pulseaudio as I'm
> interested in learning where and how it connects to Alsa?

No real docs. See the code in src/modules/alsa. Only took me a year to
figure things out :-(
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Fri, 2010-07-09 at 10:51 -0500, pl bossart wrote:
> > I agree that it's not really a good solution to require the user to
> > change the card profile manually to enable passthrough via spdif. But as
> > I said, a separate module could take care switching between the profiles
> > as needed.
>
> I don't understand your proposal. What do you mean by separate
> 'module' and how would this work with the current mixer profiles?

PA_CORE_HOOK_SINK_INPUT_NEW is fired at the beginning of
pa_sink_input_new(). A module can connect to that hook and detect that
"ah, data->flags contains PA_SINK_INPUT_PASSTHROUGH, and data->sink is
NULL, I'll make sure that the passthrough sink is available".

Configuring (automatically) such module would need some extensions to
the card profile code so that this new module could figure out what
needs to be done in order to "make sure that the passthrough sink is
available". My feeling is/was that it's probably doable without too much
difficulty, and that's about as far as I thought about it.

Now, what if data->sink is not NULL? That means that when the client
created the stream, the correct profile was already activated. Or,
alternatively, data->sink points to some "ghost" of a currently
non-existing sink that can, however, be "made real" automatically
somehow. This latter scenario refers to functionality that doesn't
currently exist. Implementing such functionality would require big
changes to a lot of stuff.

I'm starting to like your approach more and more.

> > Having thought this for a while, the only thing that really irritates me
> > in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> > messy: the flag says that "in addition to normal PCM streams, this sink
> > supports also passthrough streams, except at times when there already
> > exist PCM streams, and btw, while a passthrough stream is playing, PCM
> > streams cease to be supported". I guess that's not a very practical
> > problem, though.
>
> It's not really my design, it's just how SPDIF/HDMI work...

Well, when defining the semantics of PA_SINK_PASSTHROUGH you're free to
choose between "combined PCM and passthrough" or "passthrough only".
Either can be made to work with spdif/hdmi. And I think it's not really
specific to spdif/hdmi - both semantics can be used with any passthrough
sink. For example, using your semantics, an A2DP sink can switch between
real-time SBC encoding and passthrough MP3 on the fly similarly how an
spdif sink can change between PCM and passthrough operation. The only
case where the "combined" semantics wouldn't work is when the sink just
plain can't work in any other mode than passthrough. I think it's quite
improbable that we'll ever see such sink.

> > Ah, but now a better argument popped into my mind. If a sink can enter
> > the passthrough mode on the fly, then that has a consequence that
> > affects any application that is interested in sink volumes: whether a
> > sink has adjustable volume can change any time. That's not very nice.
>
> Duh? If we fixed the volume stuff so that that the volume control app
> disables its sliders when passthrough AC3 is enabled, what would be
> the issue. This is how VLC works, when you stream AC3 data the volume
> control is no longer enabled.

What I had in mind was that if changing between PCM and passthrough
modes would require changing profiles, then clients wouldn't need to be
prepared to disable and enable volume control for a sink on the fly.
They would only need to check whether a sink has volume when they
initially create the widget for the sink.

If volume can be disabled on the fly, that pushes more complexity to the
clients, which is not good. But actually I think we'll have to do this,
since the profile-switching module seems impractical.

It seems like all my ideas were crap :)

> > Even if we have only two formats, iec958 and mp3, I don't see why the
> > sink flags would the proper place to specify the format. I believe most
> > of the passthrough related code is only interested in the fact that the
> > stream data shall not be touched. If there are multiple flags for all
> > the different passthrough formats, then all that code will have to check
> > for two flags instead of one.
>
> I guess we could have a two-step process, where you first detect if
> the sink and sink-input have support for PASSTHROUGH, and then in a
> second step you verify that the 'subtype' (iec958 or mp3) is
> compatible. The logic for rejecting connections is the same... You
> only need one last step to make sure types are compatible.
>
> > There would of course be a standard implementation for sinks that don't
> > do any "strange" stuff. I thought individual sink implementations could
> > choose to amend the standard logic, but actually I'm not sure how it
> > could be done without duplicating code.
> >
> > Giving it a second thought, the "can this sink input be connected to
> > this sink" question can be thought equally well as a method of sinks or
> > sink inputs, or even as a plain old independent function. So, doing it
> > like you do it in your patch is fine by me (just don't use "iec958"
> > where the logic isn't really bound to the exact format).
>
> As I said above, we can have a first pass implemented in the core that
> checks things are fine, then a second pass implemented by sinks who
> support passthrough mode to check fine-grained compatibility.

I think I'd just put a new variable in pa_sink and pa_sink_input (or
maybe pa_sample_spec?) that would store the codec information, and do
all checking in the core in one place.

> >> > The NOVOLUME flags can be exported to clients, so they can choose to not
> >> > show any volume controls. Legacy clients should get the
> >> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> >> > sinks that have the NOVOLUME flag.
> >>
> >> Yes the volume needs more work. I don't really understand all this
> >> code through, so for now I disabled the set-volume() routines without
> >> notifying the client. You end-up in the situation where pavucontrol
> >> can change the volume but nothing happens, this is not user-friendly.
> >> Is this NOVOLUME flag an existing one, or something that would need to be added?
> >
> > It needs to be added.
>
> There's already a detection in the mixer code that the hw_volume is
> available or not. Maybe we can use this as well.

No, I don't think so. HW volume is a different thing. If a sink doesn't
have HW volume, then it will have SW volume. What we want to tell the
clients is that "this sink or this stream doesn't have volume at all". I
think a new flag for that is a fine solution.

I'm not sure if everyone agrees that the flags should change on the fly,
though, which will happen if a sink can disable volume whenever it
wants. An alternative is to put a new boolean variable to the
pa_sink_info struct. I don't care which solution is chosen.

At server side the situation is the same - shall we add a NOVOLUME flag
to sinks and make it possible to change the flags on the fly, or shall
we add a new "has_volume" boolean variable to pa_sink.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote:
> First this passthrough mode is only valid for S/PDIF and HDMI outputs.
> In both cases, the receiver may or may not support encoded content,
> and in the SPDIF case you have no way of querying what the receiver
> capabilities are. You absolutely do not want to send passthrough
> streams without making sure the configuration makes sense.
> So somehow user interaction is required to explicitly tell PulseAudio
> the receiver supports AC3/DTS passthrough. To be more self-explanatory
> we should have a check-box in pavucontrol than a different profile.
> I really did not want to switch configurations depending on the type
> of content, ALSA/iec958 accepts both.

I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.

Having thought this for a while, the only thing that really irritates me
in your design is that the semantics of the PA_SINK_PASSTHROUGH become
messy: the flag says that "in addition to normal PCM streams, this sink
supports also passthrough streams, except at times when there already
exist PCM streams, and btw, while a passthrough stream is playing, PCM
streams cease to be supported". I guess that's not a very practical
problem, though.

Ah, but now a better argument popped into my mind. If a sink can enter
the passthrough mode on the fly, then that has a consequence that
affects any application that is interested in sink volumes: whether a
sink has adjustable volume can change any time. That's not very nice.

> > Previously I claimed that since the the stream is compressed, we
> > inevitably will have to extend the code in pa_bytes_to_usec(), but I
> > realized now that as long as we pretend that the stream really is a
> > regular stereo stream, all calculations end up correct. Now the only
> > problem is that the user is given sort of wrong information, but I don't
> > think that's a big problem, so I agree with your approach of leaving the
> > sample spec alone and relying only on the sink and sink input flags. The
> > code can be improved later, if needed.
>
>
> > About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> > First, "non-audio" is not really correct, because the data is still
> > audio, but the main issue is the "iec958" part. There can potentially be
> > many formats that need to be passed through unchanged, so in the future
> > there could be need for PA_STREAM_NONAUDIO_FOO and
> > PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> > the format information - the format should have its own variable. Until
> > new formats are introduced, you can still rely on a single flag, though.
> > I propose that you just rename the flags:
> >
> > - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
> > - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
> > - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.
>
> I really don't think there are that many formats. The only use cases I
> can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
> audio. Adding flags on the sinks is no big deal.

Even if we have only two formats, iec958 and mp3, I don't see why the
sink flags would the proper place to specify the format. I believe most
of the passthrough related code is only interested in the fact that the
stream data shall not be touched. If there are multiple flags for all
the different passthrough formats, then all that code will have to check
for two flags instead of one.

> The real problem is at the pa_stream level. We don't want to have to
> extend the protocol several times. I added a flag but if we have more
> than one format we will need more room for subtypes. We should
> probably extend the buff_attr attributes for this?

I haven't though about this much, but I have a feeling that more complex
formats (like mp3) are going to need more metadata than currently
available (stuff like bitrate, CBR vs VBR etc.), and if support for
other codecs is going to be needed in the future, the set of metadata
items might vary between codecs. I wouldn't care about all that complex
stuff before it's implemented - in other words, I don't see it as a big
problem if the protocol will have to be extended multiple times for
different codecs. (Of course it would be nice to avoid that, but I
wouldn't trust at least myself to get it right at first try without
actually implementing the mp3 passthrough functionality at the same
time.)

> > I think the most natural place for input compatibility checking is in
> > the sink object. At least it achieves better encapsulation, because then
> > you don't need to poke the sink's "private-ish" data from outside the
> > sink object. That makes future changes easier to do.
>
> I disagree. I think you want a common logic in the core to make sure
> that things work the same way no matter what configuration you use.
> And its make sure we don't have to modify all existing sinks to
> perform the same checks.

There would of course be a standard implementation for sinks that don't
do any "strange" stuff. I thought individual sink implementations could
choose to amend the standard logic, but actually I'm not sure how it
could be done without duplicating code.

Giving it a second thought, the "can this sink input be connected to
this sink" question can be thought equally well as a method of sinks or
sink inputs, or even as a plain old independent function. So, doing it
like you do it in your patch is fine by me (just don't use "iec958"
where the logic isn't really bound to the exact format).

> > The NOVOLUME flags can be exported to clients, so they can choose to not
> > show any volume controls. Legacy clients should get the
> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> > sinks that have the NOVOLUME flag.
>
> Yes the volume needs more work. I don't really understand all this
> code through, so for now I disabled the set-volume() routines without
> notifying the client. You end-up in the situation where pavucontrol
> can change the volume but nothing happens, this is not user-friendly.
> Is this NOVOLUME flag an existing one, or something that would need to be added?

It needs to be added.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I agree that it's not really a good solution to require the user to
> change the card profile manually to enable passthrough via spdif. But as
> I said, a separate module could take care switching between the profiles
> as needed.

I don't understand your proposal. What do you mean by separate
'module' and how would this work with the current mixer profiles?

> Having thought this for a while, the only thing that really irritates me
> in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> messy: the flag says that "in addition to normal PCM streams, this sink
> supports also passthrough streams, except at times when there already
> exist PCM streams, and btw, while a passthrough stream is playing, PCM
> streams cease to be supported". I guess that's not a very practical
> problem, though.

It's not really my design, it's just how SPDIF/HDMI work...

> Ah, but now a better argument popped into my mind. If a sink can enter
> the passthrough mode on the fly, then that has a consequence that
> affects any application that is interested in sink volumes: whether a
> sink has adjustable volume can change any time. That's not very nice.

Duh? If we fixed the volume stuff so that that the volume control app
disables its sliders when passthrough AC3 is enabled, what would be
the issue. This is how VLC works, when you stream AC3 data the volume
control is no longer enabled.

> Even if we have only two formats, iec958 and mp3, I don't see why the
> sink flags would the proper place to specify the format. I believe most
> of the passthrough related code is only interested in the fact that the
> stream data shall not be touched. If there are multiple flags for all
> the different passthrough formats, then all that code will have to check
> for two flags instead of one.

I guess we could have a two-step process, where you first detect if
the sink and sink-input have support for PASSTHROUGH, and then in a
second step you verify that the 'subtype' (iec958 or mp3) is
compatible. The logic for rejecting connections is the same... You
only need one last step to make sure types are compatible.

> There would of course be a standard implementation for sinks that don't
> do any "strange" stuff. I thought individual sink implementations could
> choose to amend the standard logic, but actually I'm not sure how it
> could be done without duplicating code.
>
> Giving it a second thought, the "can this sink input be connected to
> this sink" question can be thought equally well as a method of sinks or
> sink inputs, or even as a plain old independent function. So, doing it
> like you do it in your patch is fine by me (just don't use "iec958"
> where the logic isn't really bound to the exact format).

As I said above, we can have a first pass implemented in the core that
checks things are fine, then a second pass implemented by sinks who
support passthrough mode to check fine-grained compatibility.

>> > The NOVOLUME flags can be exported to clients, so they can choose to not
>> > show any volume controls. Legacy clients should get the
>> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
>> > sinks that have the NOVOLUME flag.
>>
>> Yes the volume needs more work. I don't really understand all this
>> code through, so for now I disabled the set-volume() routines without
>> notifying the client. You end-up in the situation where pavucontrol
>> can change the volume but nothing happens, this is not user-friendly.
>> Is this NOVOLUME flag an existing one, or something that would need to be added?
>
> It needs to be added.

There's already a detection in the mixer code that the hw_volume is
available or not. Maybe we can use this as well.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or
is someone actively looking at developing it?
2. I think that encoding needs to be considered as part of the design ie. the
possibility of AC3 or MP3 encoding before output to SPDIF.

Perhaps you're already past this point, but there is an Alsa utility iecset
which returns (and can set) whether raw data or PCM is being passed to SPDIF. So
presumably the Pulseaudio passthrough for Alsa just needs to call the same
function that utility does.

Can someone point me to any design and API docs for Pulseaudio as I'm interested
in learning where and how it connects to Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > 1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point
> only or is someone actively looking at developing it?

AC3 passthrough works (see patches at start of thread). That said
there are still some opens and feedback is still welcome. I guess this
will be part of Meego at some point, but since there''s nothing hw
specific the discussion takes place in the open.

> 2. I think that encoding needs to be considered as part of the design ie.
> the possibility of AC3 or MP3 encoding before output to SPDIF.

AC3 encoding can be done by selecting the relevant profile
(ac3-iec958). The encoding takes place in alsa-lib a52 plugin. I
initially removed these profiles but took some flak for it, apparently
some people encode their multichannel streams prior to SPDIF
transmission.
I am afraid MP3 encoding in PulseAudio doesn't make sense, not
supported either by SPDIF or HDMI. And for BT use cases, you might as
well encode in SBC if you have PCM in the first place.

> Perhaps you're already past this point, but there is an Alsa utility iecset
> which returns (and can set) whether raw data or PCM is being passed to
> SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call
> the same function that utility does.

iecset sets the AES0-3 bytes, but does not handle actual data
formatting which is done by the gstreamer ac3iec958 element and by the
alsa-lib iec958 plugin. For now I don't even bother to set these bits,
they are so unreliable that receivers usually ignore them.

> Can someone point me to any design and API docs for Pulseaudio as I'm
> interested in learning where and how it connects to Alsa?

No real docs. See the code in src/modules/alsa. Only took me a year to
figure things out :-(
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Fri, 2010-07-09 at 10:51 -0500, pl bossart wrote:
> > I agree that it's not really a good solution to require the user to
> > change the card profile manually to enable passthrough via spdif. But as
> > I said, a separate module could take care switching between the profiles
> > as needed.
>
> I don't understand your proposal. What do you mean by separate
> 'module' and how would this work with the current mixer profiles?

PA_CORE_HOOK_SINK_INPUT_NEW is fired at the beginning of
pa_sink_input_new(). A module can connect to that hook and detect that
"ah, data->flags contains PA_SINK_INPUT_PASSTHROUGH, and data->sink is
NULL, I'll make sure that the passthrough sink is available".

Configuring (automatically) such module would need some extensions to
the card profile code so that this new module could figure out what
needs to be done in order to "make sure that the passthrough sink is
available". My feeling is/was that it's probably doable without too much
difficulty, and that's about as far as I thought about it.

Now, what if data->sink is not NULL? That means that when the client
created the stream, the correct profile was already activated. Or,
alternatively, data->sink points to some "ghost" of a currently
non-existing sink that can, however, be "made real" automatically
somehow. This latter scenario refers to functionality that doesn't
currently exist. Implementing such functionality would require big
changes to a lot of stuff.

I'm starting to like your approach more and more.

> > Having thought this for a while, the only thing that really irritates me
> > in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> > messy: the flag says that "in addition to normal PCM streams, this sink
> > supports also passthrough streams, except at times when there already
> > exist PCM streams, and btw, while a passthrough stream is playing, PCM
> > streams cease to be supported". I guess that's not a very practical
> > problem, though.
>
> It's not really my design, it's just how SPDIF/HDMI work...

Well, when defining the semantics of PA_SINK_PASSTHROUGH you're free to
choose between "combined PCM and passthrough" or "passthrough only".
Either can be made to work with spdif/hdmi. And I think it's not really
specific to spdif/hdmi - both semantics can be used with any passthrough
sink. For example, using your semantics, an A2DP sink can switch between
real-time SBC encoding and passthrough MP3 on the fly similarly how an
spdif sink can change between PCM and passthrough operation. The only
case where the "combined" semantics wouldn't work is when the sink just
plain can't work in any other mode than passthrough. I think it's quite
improbable that we'll ever see such sink.

> > Ah, but now a better argument popped into my mind. If a sink can enter
> > the passthrough mode on the fly, then that has a consequence that
> > affects any application that is interested in sink volumes: whether a
> > sink has adjustable volume can change any time. That's not very nice.
>
> Duh? If we fixed the volume stuff so that that the volume control app
> disables its sliders when passthrough AC3 is enabled, what would be
> the issue. This is how VLC works, when you stream AC3 data the volume
> control is no longer enabled.

What I had in mind was that if changing between PCM and passthrough
modes would require changing profiles, then clients wouldn't need to be
prepared to disable and enable volume control for a sink on the fly.
They would only need to check whether a sink has volume when they
initially create the widget for the sink.

If volume can be disabled on the fly, that pushes more complexity to the
clients, which is not good. But actually I think we'll have to do this,
since the profile-switching module seems impractical.

It seems like all my ideas were crap :)

> > Even if we have only two formats, iec958 and mp3, I don't see why the
> > sink flags would the proper place to specify the format. I believe most
> > of the passthrough related code is only interested in the fact that the
> > stream data shall not be touched. If there are multiple flags for all
> > the different passthrough formats, then all that code will have to check
> > for two flags instead of one.
>
> I guess we could have a two-step process, where you first detect if
> the sink and sink-input have support for PASSTHROUGH, and then in a
> second step you verify that the 'subtype' (iec958 or mp3) is
> compatible. The logic for rejecting connections is the same... You
> only need one last step to make sure types are compatible.
>
> > There would of course be a standard implementation for sinks that don't
> > do any "strange" stuff. I thought individual sink implementations could
> > choose to amend the standard logic, but actually I'm not sure how it
> > could be done without duplicating code.
> >
> > Giving it a second thought, the "can this sink input be connected to
> > this sink" question can be thought equally well as a method of sinks or
> > sink inputs, or even as a plain old independent function. So, doing it
> > like you do it in your patch is fine by me (just don't use "iec958"
> > where the logic isn't really bound to the exact format).
>
> As I said above, we can have a first pass implemented in the core that
> checks things are fine, then a second pass implemented by sinks who
> support passthrough mode to check fine-grained compatibility.

I think I'd just put a new variable in pa_sink and pa_sink_input (or
maybe pa_sample_spec?) that would store the codec information, and do
all checking in the core in one place.

> >> > The NOVOLUME flags can be exported to clients, so they can choose to not
> >> > show any volume controls. Legacy clients should get the
> >> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> >> > sinks that have the NOVOLUME flag.
> >>
> >> Yes the volume needs more work. I don't really understand all this
> >> code through, so for now I disabled the set-volume() routines without
> >> notifying the client. You end-up in the situation where pavucontrol
> >> can change the volume but nothing happens, this is not user-friendly.
> >> Is this NOVOLUME flag an existing one, or something that would need to be added?
> >
> > It needs to be added.
>
> There's already a detection in the mixer code that the hw_volume is
> available or not. Maybe we can use this as well.

No, I don't think so. HW volume is a different thing. If a sink doesn't
have HW volume, then it will have SW volume. What we want to tell the
clients is that "this sink or this stream doesn't have volume at all". I
think a new flag for that is a fine solution.

I'm not sure if everyone agrees that the flags should change on the fly,
though, which will happen if a sink can disable volume whenever it
wants. An alternative is to put a new boolean variable to the
pa_sink_info struct. I don't care which solution is chosen.

At server side the situation is the same - shall we add a NOVOLUME flag
to sinks and make it possible to change the flags on the fly, or shall
we add a new "has_volume" boolean variable to pa_sink.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Great news that AC3 passthrough is working. Well done!

Are there any issues with AC3 encoding as I am using the A52 plugin from
Pulseaudio (without your patch) and required the following "hacks":
a. A rate converter in asoundrc:
# Rate Converter to 48kHz, needed for Pulseaudio it seems
pcm.Filter_
RateConvert {
type rate slave {
pcm "Filter_A52Encode" rate 48000
}
}
b. A timeout=0 in default.pa

load-module module-suspend-on-idle timeout=0 # timeout=0 required

Even with these "hacks", I found that sometimes I see:
I: module.c: Unloading "module-alsa-sink" (index: #4).
D: module-always-sink.c: Autoloading null-sink as no other sinks detected.
After I see that, the sink disappears and cannot be selected any more in sound
properties.

1. Does the ac3-iec958 profile resolve any of these issues?
2. Jack has ac3jack. What would be the pros and cons of doing the AC3 encoding
in Pulseaudio instead of in Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote:
> First this passthrough mode is only valid for S/PDIF and HDMI outputs.
> In both cases, the receiver may or may not support encoded content,
> and in the SPDIF case you have no way of querying what the receiver
> capabilities are. You absolutely do not want to send passthrough
> streams without making sure the configuration makes sense.
> So somehow user interaction is required to explicitly tell PulseAudio
> the receiver supports AC3/DTS passthrough. To be more self-explanatory
> we should have a check-box in pavucontrol than a different profile.
> I really did not want to switch configurations depending on the type
> of content, ALSA/iec958 accepts both.

I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.

Having thought this for a while, the only thing that really irritates me
in your design is that the semantics of the PA_SINK_PASSTHROUGH become
messy: the flag says that "in addition to normal PCM streams, this sink
supports also passthrough streams, except at times when there already
exist PCM streams, and btw, while a passthrough stream is playing, PCM
streams cease to be supported". I guess that's not a very practical
problem, though.

Ah, but now a better argument popped into my mind. If a sink can enter
the passthrough mode on the fly, then that has a consequence that
affects any application that is interested in sink volumes: whether a
sink has adjustable volume can change any time. That's not very nice.

> > Previously I claimed that since the the stream is compressed, we
> > inevitably will have to extend the code in pa_bytes_to_usec(), but I
> > realized now that as long as we pretend that the stream really is a
> > regular stereo stream, all calculations end up correct. Now the only
> > problem is that the user is given sort of wrong information, but I don't
> > think that's a big problem, so I agree with your approach of leaving the
> > sample spec alone and relying only on the sink and sink input flags. The
> > code can be improved later, if needed.
>
>
> > About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> > First, "non-audio" is not really correct, because the data is still
> > audio, but the main issue is the "iec958" part. There can potentially be
> > many formats that need to be passed through unchanged, so in the future
> > there could be need for PA_STREAM_NONAUDIO_FOO and
> > PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> > the format information - the format should have its own variable. Until
> > new formats are introduced, you can still rely on a single flag, though.
> > I propose that you just rename the flags:
> >
> > - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
> > - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
> > - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.
>
> I really don't think there are that many formats. The only use cases I
> can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
> audio. Adding flags on the sinks is no big deal.

Even if we have only two formats, iec958 and mp3, I don't see why the
sink flags would the proper place to specify the format. I believe most
of the passthrough related code is only interested in the fact that the
stream data shall not be touched. If there are multiple flags for all
the different passthrough formats, then all that code will have to check
for two flags instead of one.

> The real problem is at the pa_stream level. We don't want to have to
> extend the protocol several times. I added a flag but if we have more
> than one format we will need more room for subtypes. We should
> probably extend the buff_attr attributes for this?

I haven't though about this much, but I have a feeling that more complex
formats (like mp3) are going to need more metadata than currently
available (stuff like bitrate, CBR vs VBR etc.), and if support for
other codecs is going to be needed in the future, the set of metadata
items might vary between codecs. I wouldn't care about all that complex
stuff before it's implemented - in other words, I don't see it as a big
problem if the protocol will have to be extended multiple times for
different codecs. (Of course it would be nice to avoid that, but I
wouldn't trust at least myself to get it right at first try without
actually implementing the mp3 passthrough functionality at the same
time.)

> > I think the most natural place for input compatibility checking is in
> > the sink object. At least it achieves better encapsulation, because then
> > you don't need to poke the sink's "private-ish" data from outside the
> > sink object. That makes future changes easier to do.
>
> I disagree. I think you want a common logic in the core to make sure
> that things work the same way no matter what configuration you use.
> And its make sure we don't have to modify all existing sinks to
> perform the same checks.

There would of course be a standard implementation for sinks that don't
do any "strange" stuff. I thought individual sink implementations could
choose to amend the standard logic, but actually I'm not sure how it
could be done without duplicating code.

Giving it a second thought, the "can this sink input be connected to
this sink" question can be thought equally well as a method of sinks or
sink inputs, or even as a plain old independent function. So, doing it
like you do it in your patch is fine by me (just don't use "iec958"
where the logic isn't really bound to the exact format).

> > The NOVOLUME flags can be exported to clients, so they can choose to not
> > show any volume controls. Legacy clients should get the
> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> > sinks that have the NOVOLUME flag.
>
> Yes the volume needs more work. I don't really understand all this
> code through, so for now I disabled the set-volume() routines without
> notifying the client. You end-up in the situation where pavucontrol
> can change the volume but nothing happens, this is not user-friendly.
> Is this NOVOLUME flag an existing one, or something that would need to be added?

It needs to be added.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I agree that it's not really a good solution to require the user to
> change the card profile manually to enable passthrough via spdif. But as
> I said, a separate module could take care switching between the profiles
> as needed.

I don't understand your proposal. What do you mean by separate
'module' and how would this work with the current mixer profiles?

> Having thought this for a while, the only thing that really irritates me
> in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> messy: the flag says that "in addition to normal PCM streams, this sink
> supports also passthrough streams, except at times when there already
> exist PCM streams, and btw, while a passthrough stream is playing, PCM
> streams cease to be supported". I guess that's not a very practical
> problem, though.

It's not really my design, it's just how SPDIF/HDMI work...

> Ah, but now a better argument popped into my mind. If a sink can enter
> the passthrough mode on the fly, then that has a consequence that
> affects any application that is interested in sink volumes: whether a
> sink has adjustable volume can change any time. That's not very nice.

Duh? If we fixed the volume stuff so that that the volume control app
disables its sliders when passthrough AC3 is enabled, what would be
the issue. This is how VLC works, when you stream AC3 data the volume
control is no longer enabled.

> Even if we have only two formats, iec958 and mp3, I don't see why the
> sink flags would the proper place to specify the format. I believe most
> of the passthrough related code is only interested in the fact that the
> stream data shall not be touched. If there are multiple flags for all
> the different passthrough formats, then all that code will have to check
> for two flags instead of one.

I guess we could have a two-step process, where you first detect if
the sink and sink-input have support for PASSTHROUGH, and then in a
second step you verify that the 'subtype' (iec958 or mp3) is
compatible. The logic for rejecting connections is the same... You
only need one last step to make sure types are compatible.

> There would of course be a standard implementation for sinks that don't
> do any "strange" stuff. I thought individual sink implementations could
> choose to amend the standard logic, but actually I'm not sure how it
> could be done without duplicating code.
>
> Giving it a second thought, the "can this sink input be connected to
> this sink" question can be thought equally well as a method of sinks or
> sink inputs, or even as a plain old independent function. So, doing it
> like you do it in your patch is fine by me (just don't use "iec958"
> where the logic isn't really bound to the exact format).

As I said above, we can have a first pass implemented in the core that
checks things are fine, then a second pass implemented by sinks who
support passthrough mode to check fine-grained compatibility.

>> > The NOVOLUME flags can be exported to clients, so they can choose to not
>> > show any volume controls. Legacy clients should get the
>> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
>> > sinks that have the NOVOLUME flag.
>>
>> Yes the volume needs more work. I don't really understand all this
>> code through, so for now I disabled the set-volume() routines without
>> notifying the client. You end-up in the situation where pavucontrol
>> can change the volume but nothing happens, this is not user-friendly.
>> Is this NOVOLUME flag an existing one, or something that would need to be added?
>
> It needs to be added.

There's already a detection in the mixer code that the hw_volume is
available or not. Maybe we can use this as well.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or
is someone actively looking at developing it?
2. I think that encoding needs to be considered as part of the design ie. the
possibility of AC3 or MP3 encoding before output to SPDIF.

Perhaps you're already past this point, but there is an Alsa utility iecset
which returns (and can set) whether raw data or PCM is being passed to SPDIF. So
presumably the Pulseaudio passthrough for Alsa just needs to call the same
function that utility does.

Can someone point me to any design and API docs for Pulseaudio as I'm interested
in learning where and how it connects to Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > 1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point
> only or is someone actively looking at developing it?

AC3 passthrough works (see patches at start of thread). That said
there are still some opens and feedback is still welcome. I guess this
will be part of Meego at some point, but since there''s nothing hw
specific the discussion takes place in the open.

> 2. I think that encoding needs to be considered as part of the design ie.
> the possibility of AC3 or MP3 encoding before output to SPDIF.

AC3 encoding can be done by selecting the relevant profile
(ac3-iec958). The encoding takes place in alsa-lib a52 plugin. I
initially removed these profiles but took some flak for it, apparently
some people encode their multichannel streams prior to SPDIF
transmission.
I am afraid MP3 encoding in PulseAudio doesn't make sense, not
supported either by SPDIF or HDMI. And for BT use cases, you might as
well encode in SBC if you have PCM in the first place.

> Perhaps you're already past this point, but there is an Alsa utility iecset
> which returns (and can set) whether raw data or PCM is being passed to
> SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call
> the same function that utility does.

iecset sets the AES0-3 bytes, but does not handle actual data
formatting which is done by the gstreamer ac3iec958 element and by the
alsa-lib iec958 plugin. For now I don't even bother to set these bits,
they are so unreliable that receivers usually ignore them.

> Can someone point me to any design and API docs for Pulseaudio as I'm
> interested in learning where and how it connects to Alsa?

No real docs. See the code in src/modules/alsa. Only took me a year to
figure things out :-(
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Fri, 2010-07-09 at 10:51 -0500, pl bossart wrote:
> > I agree that it's not really a good solution to require the user to
> > change the card profile manually to enable passthrough via spdif. But as
> > I said, a separate module could take care switching between the profiles
> > as needed.
>
> I don't understand your proposal. What do you mean by separate
> 'module' and how would this work with the current mixer profiles?

PA_CORE_HOOK_SINK_INPUT_NEW is fired at the beginning of
pa_sink_input_new(). A module can connect to that hook and detect that
"ah, data->flags contains PA_SINK_INPUT_PASSTHROUGH, and data->sink is
NULL, I'll make sure that the passthrough sink is available".

Configuring (automatically) such module would need some extensions to
the card profile code so that this new module could figure out what
needs to be done in order to "make sure that the passthrough sink is
available". My feeling is/was that it's probably doable without too much
difficulty, and that's about as far as I thought about it.

Now, what if data->sink is not NULL? That means that when the client
created the stream, the correct profile was already activated. Or,
alternatively, data->sink points to some "ghost" of a currently
non-existing sink that can, however, be "made real" automatically
somehow. This latter scenario refers to functionality that doesn't
currently exist. Implementing such functionality would require big
changes to a lot of stuff.

I'm starting to like your approach more and more.

> > Having thought this for a while, the only thing that really irritates me
> > in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> > messy: the flag says that "in addition to normal PCM streams, this sink
> > supports also passthrough streams, except at times when there already
> > exist PCM streams, and btw, while a passthrough stream is playing, PCM
> > streams cease to be supported". I guess that's not a very practical
> > problem, though.
>
> It's not really my design, it's just how SPDIF/HDMI work...

Well, when defining the semantics of PA_SINK_PASSTHROUGH you're free to
choose between "combined PCM and passthrough" or "passthrough only".
Either can be made to work with spdif/hdmi. And I think it's not really
specific to spdif/hdmi - both semantics can be used with any passthrough
sink. For example, using your semantics, an A2DP sink can switch between
real-time SBC encoding and passthrough MP3 on the fly similarly how an
spdif sink can change between PCM and passthrough operation. The only
case where the "combined" semantics wouldn't work is when the sink just
plain can't work in any other mode than passthrough. I think it's quite
improbable that we'll ever see such sink.

> > Ah, but now a better argument popped into my mind. If a sink can enter
> > the passthrough mode on the fly, then that has a consequence that
> > affects any application that is interested in sink volumes: whether a
> > sink has adjustable volume can change any time. That's not very nice.
>
> Duh? If we fixed the volume stuff so that that the volume control app
> disables its sliders when passthrough AC3 is enabled, what would be
> the issue. This is how VLC works, when you stream AC3 data the volume
> control is no longer enabled.

What I had in mind was that if changing between PCM and passthrough
modes would require changing profiles, then clients wouldn't need to be
prepared to disable and enable volume control for a sink on the fly.
They would only need to check whether a sink has volume when they
initially create the widget for the sink.

If volume can be disabled on the fly, that pushes more complexity to the
clients, which is not good. But actually I think we'll have to do this,
since the profile-switching module seems impractical.

It seems like all my ideas were crap :)

> > Even if we have only two formats, iec958 and mp3, I don't see why the
> > sink flags would the proper place to specify the format. I believe most
> > of the passthrough related code is only interested in the fact that the
> > stream data shall not be touched. If there are multiple flags for all
> > the different passthrough formats, then all that code will have to check
> > for two flags instead of one.
>
> I guess we could have a two-step process, where you first detect if
> the sink and sink-input have support for PASSTHROUGH, and then in a
> second step you verify that the 'subtype' (iec958 or mp3) is
> compatible. The logic for rejecting connections is the same... You
> only need one last step to make sure types are compatible.
>
> > There would of course be a standard implementation for sinks that don't
> > do any "strange" stuff. I thought individual sink implementations could
> > choose to amend the standard logic, but actually I'm not sure how it
> > could be done without duplicating code.
> >
> > Giving it a second thought, the "can this sink input be connected to
> > this sink" question can be thought equally well as a method of sinks or
> > sink inputs, or even as a plain old independent function. So, doing it
> > like you do it in your patch is fine by me (just don't use "iec958"
> > where the logic isn't really bound to the exact format).
>
> As I said above, we can have a first pass implemented in the core that
> checks things are fine, then a second pass implemented by sinks who
> support passthrough mode to check fine-grained compatibility.

I think I'd just put a new variable in pa_sink and pa_sink_input (or
maybe pa_sample_spec?) that would store the codec information, and do
all checking in the core in one place.

> >> > The NOVOLUME flags can be exported to clients, so they can choose to not
> >> > show any volume controls. Legacy clients should get the
> >> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> >> > sinks that have the NOVOLUME flag.
> >>
> >> Yes the volume needs more work. I don't really understand all this
> >> code through, so for now I disabled the set-volume() routines without
> >> notifying the client. You end-up in the situation where pavucontrol
> >> can change the volume but nothing happens, this is not user-friendly.
> >> Is this NOVOLUME flag an existing one, or something that would need to be added?
> >
> > It needs to be added.
>
> There's already a detection in the mixer code that the hw_volume is
> available or not. Maybe we can use this as well.

No, I don't think so. HW volume is a different thing. If a sink doesn't
have HW volume, then it will have SW volume. What we want to tell the
clients is that "this sink or this stream doesn't have volume at all". I
think a new flag for that is a fine solution.

I'm not sure if everyone agrees that the flags should change on the fly,
though, which will happen if a sink can disable volume whenever it
wants. An alternative is to put a new boolean variable to the
pa_sink_info struct. I don't care which solution is chosen.

At server side the situation is the same - shall we add a NOVOLUME flag
to sinks and make it possible to change the flags on the fly, or shall
we add a new "has_volume" boolean variable to pa_sink.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Great news that AC3 passthrough is working. Well done!

Are there any issues with AC3 encoding as I am using the A52 plugin from
Pulseaudio (without your patch) and required the following "hacks":
a. A rate converter in asoundrc:
# Rate Converter to 48kHz, needed for Pulseaudio it seems
pcm.Filter_
RateConvert {
type rate slave {
pcm "Filter_A52Encode" rate 48000
}
}
b. A timeout=0 in default.pa

load-module module-suspend-on-idle timeout=0 # timeout=0 required

Even with these "hacks", I found that sometimes I see:
I: module.c: Unloading "module-alsa-sink" (index: #4).
D: module-always-sink.c: Autoloading null-sink as no other sinks detected.
After I see that, the sink disappears and cannot be selected any more in sound
properties.

1. Does the ac3-iec958 profile resolve any of these issues?
2. Jack has ac3jack. What would be the pros and cons of doing the AC3 encoding
in Pulseaudio instead of in Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Sat, 2010-07-10 at 08:05 +0000, Michael Rans wrote:
> Even with these "hacks", I found that sometimes I see:
>
> I: module.c: Unloading "module-alsa-sink" (index: #4).
> D: module-always-sink.c: Autoloading null-sink as no other sinks
> detected.
>
>
> After I see that, the sink disappears and cannot be selected any more
> in sound properties.
>
> 1. Does the ac3-iec958 profile resolve any of these issues?

What's "the ac3-iec958 profile"? The iec958-ac3-surround-* mappings that
currently exist in pulseaudio use the a52 alsa plugin, which may or may
not work with Colin's patch[1]. (It didn't work for Colin.)

> 2. Jack has ac3jack. What would be the pros and cons of doing the AC3
> encoding in Pulseaudio instead of in Alsa?

I think it would make sense to do AC3 encoding in Pulseaudio, although
in theory I don't see what difference it would make. Maybe it's somehow
benefical to handle all the buffering inside Pulseaudio. If there are
timing related bugs in the a52 plugin, as Colin seems to think there
are, then it's also a matter of who volunteers first: a person who knows
how to fix the a52 plugin, or a person who knows how to hack AC3
encoding support into Pulseaudio.

[1] https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-June/007311.html

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote:
> First this passthrough mode is only valid for S/PDIF and HDMI outputs.
> In both cases, the receiver may or may not support encoded content,
> and in the SPDIF case you have no way of querying what the receiver
> capabilities are. You absolutely do not want to send passthrough
> streams without making sure the configuration makes sense.
> So somehow user interaction is required to explicitly tell PulseAudio
> the receiver supports AC3/DTS passthrough. To be more self-explanatory
> we should have a check-box in pavucontrol than a different profile.
> I really did not want to switch configurations depending on the type
> of content, ALSA/iec958 accepts both.

I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.

Having thought this for a while, the only thing that really irritates me
in your design is that the semantics of the PA_SINK_PASSTHROUGH become
messy: the flag says that "in addition to normal PCM streams, this sink
supports also passthrough streams, except at times when there already
exist PCM streams, and btw, while a passthrough stream is playing, PCM
streams cease to be supported". I guess that's not a very practical
problem, though.

Ah, but now a better argument popped into my mind. If a sink can enter
the passthrough mode on the fly, then that has a consequence that
affects any application that is interested in sink volumes: whether a
sink has adjustable volume can change any time. That's not very nice.

> > Previously I claimed that since the the stream is compressed, we
> > inevitably will have to extend the code in pa_bytes_to_usec(), but I
> > realized now that as long as we pretend that the stream really is a
> > regular stereo stream, all calculations end up correct. Now the only
> > problem is that the user is given sort of wrong information, but I don't
> > think that's a big problem, so I agree with your approach of leaving the
> > sample spec alone and relying only on the sink and sink input flags. The
> > code can be improved later, if needed.
>
>
> > About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> > First, "non-audio" is not really correct, because the data is still
> > audio, but the main issue is the "iec958" part. There can potentially be
> > many formats that need to be passed through unchanged, so in the future
> > there could be need for PA_STREAM_NONAUDIO_FOO and
> > PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> > the format information - the format should have its own variable. Until
> > new formats are introduced, you can still rely on a single flag, though.
> > I propose that you just rename the flags:
> >
> > - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
> > - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
> > - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.
>
> I really don't think there are that many formats. The only use cases I
> can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
> audio. Adding flags on the sinks is no big deal.

Even if we have only two formats, iec958 and mp3, I don't see why the
sink flags would the proper place to specify the format. I believe most
of the passthrough related code is only interested in the fact that the
stream data shall not be touched. If there are multiple flags for all
the different passthrough formats, then all that code will have to check
for two flags instead of one.

> The real problem is at the pa_stream level. We don't want to have to
> extend the protocol several times. I added a flag but if we have more
> than one format we will need more room for subtypes. We should
> probably extend the buff_attr attributes for this?

I haven't though about this much, but I have a feeling that more complex
formats (like mp3) are going to need more metadata than currently
available (stuff like bitrate, CBR vs VBR etc.), and if support for
other codecs is going to be needed in the future, the set of metadata
items might vary between codecs. I wouldn't care about all that complex
stuff before it's implemented - in other words, I don't see it as a big
problem if the protocol will have to be extended multiple times for
different codecs. (Of course it would be nice to avoid that, but I
wouldn't trust at least myself to get it right at first try without
actually implementing the mp3 passthrough functionality at the same
time.)

> > I think the most natural place for input compatibility checking is in
> > the sink object. At least it achieves better encapsulation, because then
> > you don't need to poke the sink's "private-ish" data from outside the
> > sink object. That makes future changes easier to do.
>
> I disagree. I think you want a common logic in the core to make sure
> that things work the same way no matter what configuration you use.
> And its make sure we don't have to modify all existing sinks to
> perform the same checks.

There would of course be a standard implementation for sinks that don't
do any "strange" stuff. I thought individual sink implementations could
choose to amend the standard logic, but actually I'm not sure how it
could be done without duplicating code.

Giving it a second thought, the "can this sink input be connected to
this sink" question can be thought equally well as a method of sinks or
sink inputs, or even as a plain old independent function. So, doing it
like you do it in your patch is fine by me (just don't use "iec958"
where the logic isn't really bound to the exact format).

> > The NOVOLUME flags can be exported to clients, so they can choose to not
> > show any volume controls. Legacy clients should get the
> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> > sinks that have the NOVOLUME flag.
>
> Yes the volume needs more work. I don't really understand all this
> code through, so for now I disabled the set-volume() routines without
> notifying the client. You end-up in the situation where pavucontrol
> can change the volume but nothing happens, this is not user-friendly.
> Is this NOVOLUME flag an existing one, or something that would need to be added?

It needs to be added.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I agree that it's not really a good solution to require the user to
> change the card profile manually to enable passthrough via spdif. But as
> I said, a separate module could take care switching between the profiles
> as needed.

I don't understand your proposal. What do you mean by separate
'module' and how would this work with the current mixer profiles?

> Having thought this for a while, the only thing that really irritates me
> in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> messy: the flag says that "in addition to normal PCM streams, this sink
> supports also passthrough streams, except at times when there already
> exist PCM streams, and btw, while a passthrough stream is playing, PCM
> streams cease to be supported". I guess that's not a very practical
> problem, though.

It's not really my design, it's just how SPDIF/HDMI work...

> Ah, but now a better argument popped into my mind. If a sink can enter
> the passthrough mode on the fly, then that has a consequence that
> affects any application that is interested in sink volumes: whether a
> sink has adjustable volume can change any time. That's not very nice.

Duh? If we fixed the volume stuff so that that the volume control app
disables its sliders when passthrough AC3 is enabled, what would be
the issue. This is how VLC works, when you stream AC3 data the volume
control is no longer enabled.

> Even if we have only two formats, iec958 and mp3, I don't see why the
> sink flags would the proper place to specify the format. I believe most
> of the passthrough related code is only interested in the fact that the
> stream data shall not be touched. If there are multiple flags for all
> the different passthrough formats, then all that code will have to check
> for two flags instead of one.

I guess we could have a two-step process, where you first detect if
the sink and sink-input have support for PASSTHROUGH, and then in a
second step you verify that the 'subtype' (iec958 or mp3) is
compatible. The logic for rejecting connections is the same... You
only need one last step to make sure types are compatible.

> There would of course be a standard implementation for sinks that don't
> do any "strange" stuff. I thought individual sink implementations could
> choose to amend the standard logic, but actually I'm not sure how it
> could be done without duplicating code.
>
> Giving it a second thought, the "can this sink input be connected to
> this sink" question can be thought equally well as a method of sinks or
> sink inputs, or even as a plain old independent function. So, doing it
> like you do it in your patch is fine by me (just don't use "iec958"
> where the logic isn't really bound to the exact format).

As I said above, we can have a first pass implemented in the core that
checks things are fine, then a second pass implemented by sinks who
support passthrough mode to check fine-grained compatibility.

>> > The NOVOLUME flags can be exported to clients, so they can choose to not
>> > show any volume controls. Legacy clients should get the
>> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
>> > sinks that have the NOVOLUME flag.
>>
>> Yes the volume needs more work. I don't really understand all this
>> code through, so for now I disabled the set-volume() routines without
>> notifying the client. You end-up in the situation where pavucontrol
>> can change the volume but nothing happens, this is not user-friendly.
>> Is this NOVOLUME flag an existing one, or something that would need to be added?
>
> It needs to be added.

There's already a detection in the mixer code that the hw_volume is
available or not. Maybe we can use this as well.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or
is someone actively looking at developing it?
2. I think that encoding needs to be considered as part of the design ie. the
possibility of AC3 or MP3 encoding before output to SPDIF.

Perhaps you're already past this point, but there is an Alsa utility iecset
which returns (and can set) whether raw data or PCM is being passed to SPDIF. So
presumably the Pulseaudio passthrough for Alsa just needs to call the same
function that utility does.

Can someone point me to any design and API docs for Pulseaudio as I'm interested
in learning where and how it connects to Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > 1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point
> only or is someone actively looking at developing it?

AC3 passthrough works (see patches at start of thread). That said
there are still some opens and feedback is still welcome. I guess this
will be part of Meego at some point, but since there''s nothing hw
specific the discussion takes place in the open.

> 2. I think that encoding needs to be considered as part of the design ie.
> the possibility of AC3 or MP3 encoding before output to SPDIF.

AC3 encoding can be done by selecting the relevant profile
(ac3-iec958). The encoding takes place in alsa-lib a52 plugin. I
initially removed these profiles but took some flak for it, apparently
some people encode their multichannel streams prior to SPDIF
transmission.
I am afraid MP3 encoding in PulseAudio doesn't make sense, not
supported either by SPDIF or HDMI. And for BT use cases, you might as
well encode in SBC if you have PCM in the first place.

> Perhaps you're already past this point, but there is an Alsa utility iecset
> which returns (and can set) whether raw data or PCM is being passed to
> SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call
> the same function that utility does.

iecset sets the AES0-3 bytes, but does not handle actual data
formatting which is done by the gstreamer ac3iec958 element and by the
alsa-lib iec958 plugin. For now I don't even bother to set these bits,
they are so unreliable that receivers usually ignore them.

> Can someone point me to any design and API docs for Pulseaudio as I'm
> interested in learning where and how it connects to Alsa?

No real docs. See the code in src/modules/alsa. Only took me a year to
figure things out :-(
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Fri, 2010-07-09 at 10:51 -0500, pl bossart wrote:
> > I agree that it's not really a good solution to require the user to
> > change the card profile manually to enable passthrough via spdif. But as
> > I said, a separate module could take care switching between the profiles
> > as needed.
>
> I don't understand your proposal. What do you mean by separate
> 'module' and how would this work with the current mixer profiles?

PA_CORE_HOOK_SINK_INPUT_NEW is fired at the beginning of
pa_sink_input_new(). A module can connect to that hook and detect that
"ah, data->flags contains PA_SINK_INPUT_PASSTHROUGH, and data->sink is
NULL, I'll make sure that the passthrough sink is available".

Configuring (automatically) such module would need some extensions to
the card profile code so that this new module could figure out what
needs to be done in order to "make sure that the passthrough sink is
available". My feeling is/was that it's probably doable without too much
difficulty, and that's about as far as I thought about it.

Now, what if data->sink is not NULL? That means that when the client
created the stream, the correct profile was already activated. Or,
alternatively, data->sink points to some "ghost" of a currently
non-existing sink that can, however, be "made real" automatically
somehow. This latter scenario refers to functionality that doesn't
currently exist. Implementing such functionality would require big
changes to a lot of stuff.

I'm starting to like your approach more and more.

> > Having thought this for a while, the only thing that really irritates me
> > in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> > messy: the flag says that "in addition to normal PCM streams, this sink
> > supports also passthrough streams, except at times when there already
> > exist PCM streams, and btw, while a passthrough stream is playing, PCM
> > streams cease to be supported". I guess that's not a very practical
> > problem, though.
>
> It's not really my design, it's just how SPDIF/HDMI work...

Well, when defining the semantics of PA_SINK_PASSTHROUGH you're free to
choose between "combined PCM and passthrough" or "passthrough only".
Either can be made to work with spdif/hdmi. And I think it's not really
specific to spdif/hdmi - both semantics can be used with any passthrough
sink. For example, using your semantics, an A2DP sink can switch between
real-time SBC encoding and passthrough MP3 on the fly similarly how an
spdif sink can change between PCM and passthrough operation. The only
case where the "combined" semantics wouldn't work is when the sink just
plain can't work in any other mode than passthrough. I think it's quite
improbable that we'll ever see such sink.

> > Ah, but now a better argument popped into my mind. If a sink can enter
> > the passthrough mode on the fly, then that has a consequence that
> > affects any application that is interested in sink volumes: whether a
> > sink has adjustable volume can change any time. That's not very nice.
>
> Duh? If we fixed the volume stuff so that that the volume control app
> disables its sliders when passthrough AC3 is enabled, what would be
> the issue. This is how VLC works, when you stream AC3 data the volume
> control is no longer enabled.

What I had in mind was that if changing between PCM and passthrough
modes would require changing profiles, then clients wouldn't need to be
prepared to disable and enable volume control for a sink on the fly.
They would only need to check whether a sink has volume when they
initially create the widget for the sink.

If volume can be disabled on the fly, that pushes more complexity to the
clients, which is not good. But actually I think we'll have to do this,
since the profile-switching module seems impractical.

It seems like all my ideas were crap :)

> > Even if we have only two formats, iec958 and mp3, I don't see why the
> > sink flags would the proper place to specify the format. I believe most
> > of the passthrough related code is only interested in the fact that the
> > stream data shall not be touched. If there are multiple flags for all
> > the different passthrough formats, then all that code will have to check
> > for two flags instead of one.
>
> I guess we could have a two-step process, where you first detect if
> the sink and sink-input have support for PASSTHROUGH, and then in a
> second step you verify that the 'subtype' (iec958 or mp3) is
> compatible. The logic for rejecting connections is the same... You
> only need one last step to make sure types are compatible.
>
> > There would of course be a standard implementation for sinks that don't
> > do any "strange" stuff. I thought individual sink implementations could
> > choose to amend the standard logic, but actually I'm not sure how it
> > could be done without duplicating code.
> >
> > Giving it a second thought, the "can this sink input be connected to
> > this sink" question can be thought equally well as a method of sinks or
> > sink inputs, or even as a plain old independent function. So, doing it
> > like you do it in your patch is fine by me (just don't use "iec958"
> > where the logic isn't really bound to the exact format).
>
> As I said above, we can have a first pass implemented in the core that
> checks things are fine, then a second pass implemented by sinks who
> support passthrough mode to check fine-grained compatibility.

I think I'd just put a new variable in pa_sink and pa_sink_input (or
maybe pa_sample_spec?) that would store the codec information, and do
all checking in the core in one place.

> >> > The NOVOLUME flags can be exported to clients, so they can choose to not
> >> > show any volume controls. Legacy clients should get the
> >> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> >> > sinks that have the NOVOLUME flag.
> >>
> >> Yes the volume needs more work. I don't really understand all this
> >> code through, so for now I disabled the set-volume() routines without
> >> notifying the client. You end-up in the situation where pavucontrol
> >> can change the volume but nothing happens, this is not user-friendly.
> >> Is this NOVOLUME flag an existing one, or something that would need to be added?
> >
> > It needs to be added.
>
> There's already a detection in the mixer code that the hw_volume is
> available or not. Maybe we can use this as well.

No, I don't think so. HW volume is a different thing. If a sink doesn't
have HW volume, then it will have SW volume. What we want to tell the
clients is that "this sink or this stream doesn't have volume at all". I
think a new flag for that is a fine solution.

I'm not sure if everyone agrees that the flags should change on the fly,
though, which will happen if a sink can disable volume whenever it
wants. An alternative is to put a new boolean variable to the
pa_sink_info struct. I don't care which solution is chosen.

At server side the situation is the same - shall we add a NOVOLUME flag
to sinks and make it possible to change the flags on the fly, or shall
we add a new "has_volume" boolean variable to pa_sink.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Great news that AC3 passthrough is working. Well done!

Are there any issues with AC3 encoding as I am using the A52 plugin from
Pulseaudio (without your patch) and required the following "hacks":
a. A rate converter in asoundrc:
# Rate Converter to 48kHz, needed for Pulseaudio it seems
pcm.Filter_
RateConvert {
type rate slave {
pcm "Filter_A52Encode" rate 48000
}
}
b. A timeout=0 in default.pa

load-module module-suspend-on-idle timeout=0 # timeout=0 required

Even with these "hacks", I found that sometimes I see:
I: module.c: Unloading "module-alsa-sink" (index: #4).
D: module-always-sink.c: Autoloading null-sink as no other sinks detected.
After I see that, the sink disappears and cannot be selected any more in sound
properties.

1. Does the ac3-iec958 profile resolve any of these issues?
2. Jack has ac3jack. What would be the pros and cons of doing the AC3 encoding
in Pulseaudio instead of in Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Sat, 2010-07-10 at 08:05 +0000, Michael Rans wrote:
> Even with these "hacks", I found that sometimes I see:
>
> I: module.c: Unloading "module-alsa-sink" (index: #4).
> D: module-always-sink.c: Autoloading null-sink as no other sinks
> detected.
>
>
> After I see that, the sink disappears and cannot be selected any more
> in sound properties.
>
> 1. Does the ac3-iec958 profile resolve any of these issues?

What's "the ac3-iec958 profile"? The iec958-ac3-surround-* mappings that
currently exist in pulseaudio use the a52 alsa plugin, which may or may
not work with Colin's patch[1]. (It didn't work for Colin.)

> 2. Jack has ac3jack. What would be the pros and cons of doing the AC3
> encoding in Pulseaudio instead of in Alsa?

I think it would make sense to do AC3 encoding in Pulseaudio, although
in theory I don't see what difference it would make. Maybe it's somehow
benefical to handle all the buffering inside Pulseaudio. If there are
timing related bugs in the a52 plugin, as Colin seems to think there
are, then it's also a matter of who volunteers first: a person who knows
how to fix the a52 plugin, or a person who knows how to hack AC3
encoding support into Pulseaudio.

[1] https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-June/007311.html

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Thanks for your reply both to my message and the bug I posted.

I tried Colin's patch, but it didn't work for me.

I tried the following evil hack in alsa-sink.c:
out_frames = snd_pcm_rewind(u->pcm_handle, (snd_pcm_uframes_t)
in_frames);
if (out_frames < 0) {
out_frames = -out_frames;
}
/* if ((out_frames = snd_pcm_rewind(u->pcm_handle, (snd_pcm_uframes_t)
in_frames)) < 0) {
pa_log("snd_pcm_rewind() failed: %s", pa_alsa_strerror((int)
out_frames));
if (try_recover(u, "process_rewind", out_frames) < 0)
return -1;
out_frames = 0;
}*/

The sound played but very very fast in Oolite, so I would say it almost worked.

I can't find any definition of snd_pcm_rewind() in the alsa-plugins source code.
Does this function call through to a function in the plugins?

I understand that there a function snd_pcm_hw_params_can_rewind which I would
guess should return false for AC3 encoding - is this called by Pulseaudio?

Cheers,
Mike





________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote:
> First this passthrough mode is only valid for S/PDIF and HDMI outputs.
> In both cases, the receiver may or may not support encoded content,
> and in the SPDIF case you have no way of querying what the receiver
> capabilities are. You absolutely do not want to send passthrough
> streams without making sure the configuration makes sense.
> So somehow user interaction is required to explicitly tell PulseAudio
> the receiver supports AC3/DTS passthrough. To be more self-explanatory
> we should have a check-box in pavucontrol than a different profile.
> I really did not want to switch configurations depending on the type
> of content, ALSA/iec958 accepts both.

I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.

Having thought this for a while, the only thing that really irritates me
in your design is that the semantics of the PA_SINK_PASSTHROUGH become
messy: the flag says that "in addition to normal PCM streams, this sink
supports also passthrough streams, except at times when there already
exist PCM streams, and btw, while a passthrough stream is playing, PCM
streams cease to be supported". I guess that's not a very practical
problem, though.

Ah, but now a better argument popped into my mind. If a sink can enter
the passthrough mode on the fly, then that has a consequence that
affects any application that is interested in sink volumes: whether a
sink has adjustable volume can change any time. That's not very nice.

> > Previously I claimed that since the the stream is compressed, we
> > inevitably will have to extend the code in pa_bytes_to_usec(), but I
> > realized now that as long as we pretend that the stream really is a
> > regular stereo stream, all calculations end up correct. Now the only
> > problem is that the user is given sort of wrong information, but I don't
> > think that's a big problem, so I agree with your approach of leaving the
> > sample spec alone and relying only on the sink and sink input flags. The
> > code can be improved later, if needed.
>
>
> > About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> > First, "non-audio" is not really correct, because the data is still
> > audio, but the main issue is the "iec958" part. There can potentially be
> > many formats that need to be passed through unchanged, so in the future
> > there could be need for PA_STREAM_NONAUDIO_FOO and
> > PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> > the format information - the format should have its own variable. Until
> > new formats are introduced, you can still rely on a single flag, though.
> > I propose that you just rename the flags:
> >
> > - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
> > - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
> > - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.
>
> I really don't think there are that many formats. The only use cases I
> can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
> audio. Adding flags on the sinks is no big deal.

Even if we have only two formats, iec958 and mp3, I don't see why the
sink flags would the proper place to specify the format. I believe most
of the passthrough related code is only interested in the fact that the
stream data shall not be touched. If there are multiple flags for all
the different passthrough formats, then all that code will have to check
for two flags instead of one.

> The real problem is at the pa_stream level. We don't want to have to
> extend the protocol several times. I added a flag but if we have more
> than one format we will need more room for subtypes. We should
> probably extend the buff_attr attributes for this?

I haven't though about this much, but I have a feeling that more complex
formats (like mp3) are going to need more metadata than currently
available (stuff like bitrate, CBR vs VBR etc.), and if support for
other codecs is going to be needed in the future, the set of metadata
items might vary between codecs. I wouldn't care about all that complex
stuff before it's implemented - in other words, I don't see it as a big
problem if the protocol will have to be extended multiple times for
different codecs. (Of course it would be nice to avoid that, but I
wouldn't trust at least myself to get it right at first try without
actually implementing the mp3 passthrough functionality at the same
time.)

> > I think the most natural place for input compatibility checking is in
> > the sink object. At least it achieves better encapsulation, because then
> > you don't need to poke the sink's "private-ish" data from outside the
> > sink object. That makes future changes easier to do.
>
> I disagree. I think you want a common logic in the core to make sure
> that things work the same way no matter what configuration you use.
> And its make sure we don't have to modify all existing sinks to
> perform the same checks.

There would of course be a standard implementation for sinks that don't
do any "strange" stuff. I thought individual sink implementations could
choose to amend the standard logic, but actually I'm not sure how it
could be done without duplicating code.

Giving it a second thought, the "can this sink input be connected to
this sink" question can be thought equally well as a method of sinks or
sink inputs, or even as a plain old independent function. So, doing it
like you do it in your patch is fine by me (just don't use "iec958"
where the logic isn't really bound to the exact format).

> > The NOVOLUME flags can be exported to clients, so they can choose to not
> > show any volume controls. Legacy clients should get the
> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> > sinks that have the NOVOLUME flag.
>
> Yes the volume needs more work. I don't really understand all this
> code through, so for now I disabled the set-volume() routines without
> notifying the client. You end-up in the situation where pavucontrol
> can change the volume but nothing happens, this is not user-friendly.
> Is this NOVOLUME flag an existing one, or something that would need to be added?

It needs to be added.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I agree that it's not really a good solution to require the user to
> change the card profile manually to enable passthrough via spdif. But as
> I said, a separate module could take care switching between the profiles
> as needed.

I don't understand your proposal. What do you mean by separate
'module' and how would this work with the current mixer profiles?

> Having thought this for a while, the only thing that really irritates me
> in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> messy: the flag says that "in addition to normal PCM streams, this sink
> supports also passthrough streams, except at times when there already
> exist PCM streams, and btw, while a passthrough stream is playing, PCM
> streams cease to be supported". I guess that's not a very practical
> problem, though.

It's not really my design, it's just how SPDIF/HDMI work...

> Ah, but now a better argument popped into my mind. If a sink can enter
> the passthrough mode on the fly, then that has a consequence that
> affects any application that is interested in sink volumes: whether a
> sink has adjustable volume can change any time. That's not very nice.

Duh? If we fixed the volume stuff so that that the volume control app
disables its sliders when passthrough AC3 is enabled, what would be
the issue. This is how VLC works, when you stream AC3 data the volume
control is no longer enabled.

> Even if we have only two formats, iec958 and mp3, I don't see why the
> sink flags would the proper place to specify the format. I believe most
> of the passthrough related code is only interested in the fact that the
> stream data shall not be touched. If there are multiple flags for all
> the different passthrough formats, then all that code will have to check
> for two flags instead of one.

I guess we could have a two-step process, where you first detect if
the sink and sink-input have support for PASSTHROUGH, and then in a
second step you verify that the 'subtype' (iec958 or mp3) is
compatible. The logic for rejecting connections is the same... You
only need one last step to make sure types are compatible.

> There would of course be a standard implementation for sinks that don't
> do any "strange" stuff. I thought individual sink implementations could
> choose to amend the standard logic, but actually I'm not sure how it
> could be done without duplicating code.
>
> Giving it a second thought, the "can this sink input be connected to
> this sink" question can be thought equally well as a method of sinks or
> sink inputs, or even as a plain old independent function. So, doing it
> like you do it in your patch is fine by me (just don't use "iec958"
> where the logic isn't really bound to the exact format).

As I said above, we can have a first pass implemented in the core that
checks things are fine, then a second pass implemented by sinks who
support passthrough mode to check fine-grained compatibility.

>> > The NOVOLUME flags can be exported to clients, so they can choose to not
>> > show any volume controls. Legacy clients should get the
>> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
>> > sinks that have the NOVOLUME flag.
>>
>> Yes the volume needs more work. I don't really understand all this
>> code through, so for now I disabled the set-volume() routines without
>> notifying the client. You end-up in the situation where pavucontrol
>> can change the volume but nothing happens, this is not user-friendly.
>> Is this NOVOLUME flag an existing one, or something that would need to be added?
>
> It needs to be added.

There's already a detection in the mixer code that the hw_volume is
available or not. Maybe we can use this as well.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or
is someone actively looking at developing it?
2. I think that encoding needs to be considered as part of the design ie. the
possibility of AC3 or MP3 encoding before output to SPDIF.

Perhaps you're already past this point, but there is an Alsa utility iecset
which returns (and can set) whether raw data or PCM is being passed to SPDIF. So
presumably the Pulseaudio passthrough for Alsa just needs to call the same
function that utility does.

Can someone point me to any design and API docs for Pulseaudio as I'm interested
in learning where and how it connects to Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > 1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point
> only or is someone actively looking at developing it?

AC3 passthrough works (see patches at start of thread). That said
there are still some opens and feedback is still welcome. I guess this
will be part of Meego at some point, but since there''s nothing hw
specific the discussion takes place in the open.

> 2. I think that encoding needs to be considered as part of the design ie.
> the possibility of AC3 or MP3 encoding before output to SPDIF.

AC3 encoding can be done by selecting the relevant profile
(ac3-iec958). The encoding takes place in alsa-lib a52 plugin. I
initially removed these profiles but took some flak for it, apparently
some people encode their multichannel streams prior to SPDIF
transmission.
I am afraid MP3 encoding in PulseAudio doesn't make sense, not
supported either by SPDIF or HDMI. And for BT use cases, you might as
well encode in SBC if you have PCM in the first place.

> Perhaps you're already past this point, but there is an Alsa utility iecset
> which returns (and can set) whether raw data or PCM is being passed to
> SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call
> the same function that utility does.

iecset sets the AES0-3 bytes, but does not handle actual data
formatting which is done by the gstreamer ac3iec958 element and by the
alsa-lib iec958 plugin. For now I don't even bother to set these bits,
they are so unreliable that receivers usually ignore them.

> Can someone point me to any design and API docs for Pulseaudio as I'm
> interested in learning where and how it connects to Alsa?

No real docs. See the code in src/modules/alsa. Only took me a year to
figure things out :-(
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Fri, 2010-07-09 at 10:51 -0500, pl bossart wrote:
> > I agree that it's not really a good solution to require the user to
> > change the card profile manually to enable passthrough via spdif. But as
> > I said, a separate module could take care switching between the profiles
> > as needed.
>
> I don't understand your proposal. What do you mean by separate
> 'module' and how would this work with the current mixer profiles?

PA_CORE_HOOK_SINK_INPUT_NEW is fired at the beginning of
pa_sink_input_new(). A module can connect to that hook and detect that
"ah, data->flags contains PA_SINK_INPUT_PASSTHROUGH, and data->sink is
NULL, I'll make sure that the passthrough sink is available".

Configuring (automatically) such module would need some extensions to
the card profile code so that this new module could figure out what
needs to be done in order to "make sure that the passthrough sink is
available". My feeling is/was that it's probably doable without too much
difficulty, and that's about as far as I thought about it.

Now, what if data->sink is not NULL? That means that when the client
created the stream, the correct profile was already activated. Or,
alternatively, data->sink points to some "ghost" of a currently
non-existing sink that can, however, be "made real" automatically
somehow. This latter scenario refers to functionality that doesn't
currently exist. Implementing such functionality would require big
changes to a lot of stuff.

I'm starting to like your approach more and more.

> > Having thought this for a while, the only thing that really irritates me
> > in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> > messy: the flag says that "in addition to normal PCM streams, this sink
> > supports also passthrough streams, except at times when there already
> > exist PCM streams, and btw, while a passthrough stream is playing, PCM
> > streams cease to be supported". I guess that's not a very practical
> > problem, though.
>
> It's not really my design, it's just how SPDIF/HDMI work...

Well, when defining the semantics of PA_SINK_PASSTHROUGH you're free to
choose between "combined PCM and passthrough" or "passthrough only".
Either can be made to work with spdif/hdmi. And I think it's not really
specific to spdif/hdmi - both semantics can be used with any passthrough
sink. For example, using your semantics, an A2DP sink can switch between
real-time SBC encoding and passthrough MP3 on the fly similarly how an
spdif sink can change between PCM and passthrough operation. The only
case where the "combined" semantics wouldn't work is when the sink just
plain can't work in any other mode than passthrough. I think it's quite
improbable that we'll ever see such sink.

> > Ah, but now a better argument popped into my mind. If a sink can enter
> > the passthrough mode on the fly, then that has a consequence that
> > affects any application that is interested in sink volumes: whether a
> > sink has adjustable volume can change any time. That's not very nice.
>
> Duh? If we fixed the volume stuff so that that the volume control app
> disables its sliders when passthrough AC3 is enabled, what would be
> the issue. This is how VLC works, when you stream AC3 data the volume
> control is no longer enabled.

What I had in mind was that if changing between PCM and passthrough
modes would require changing profiles, then clients wouldn't need to be
prepared to disable and enable volume control for a sink on the fly.
They would only need to check whether a sink has volume when they
initially create the widget for the sink.

If volume can be disabled on the fly, that pushes more complexity to the
clients, which is not good. But actually I think we'll have to do this,
since the profile-switching module seems impractical.

It seems like all my ideas were crap :)

> > Even if we have only two formats, iec958 and mp3, I don't see why the
> > sink flags would the proper place to specify the format. I believe most
> > of the passthrough related code is only interested in the fact that the
> > stream data shall not be touched. If there are multiple flags for all
> > the different passthrough formats, then all that code will have to check
> > for two flags instead of one.
>
> I guess we could have a two-step process, where you first detect if
> the sink and sink-input have support for PASSTHROUGH, and then in a
> second step you verify that the 'subtype' (iec958 or mp3) is
> compatible. The logic for rejecting connections is the same... You
> only need one last step to make sure types are compatible.
>
> > There would of course be a standard implementation for sinks that don't
> > do any "strange" stuff. I thought individual sink implementations could
> > choose to amend the standard logic, but actually I'm not sure how it
> > could be done without duplicating code.
> >
> > Giving it a second thought, the "can this sink input be connected to
> > this sink" question can be thought equally well as a method of sinks or
> > sink inputs, or even as a plain old independent function. So, doing it
> > like you do it in your patch is fine by me (just don't use "iec958"
> > where the logic isn't really bound to the exact format).
>
> As I said above, we can have a first pass implemented in the core that
> checks things are fine, then a second pass implemented by sinks who
> support passthrough mode to check fine-grained compatibility.

I think I'd just put a new variable in pa_sink and pa_sink_input (or
maybe pa_sample_spec?) that would store the codec information, and do
all checking in the core in one place.

> >> > The NOVOLUME flags can be exported to clients, so they can choose to not
> >> > show any volume controls. Legacy clients should get the
> >> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> >> > sinks that have the NOVOLUME flag.
> >>
> >> Yes the volume needs more work. I don't really understand all this
> >> code through, so for now I disabled the set-volume() routines without
> >> notifying the client. You end-up in the situation where pavucontrol
> >> can change the volume but nothing happens, this is not user-friendly.
> >> Is this NOVOLUME flag an existing one, or something that would need to be added?
> >
> > It needs to be added.
>
> There's already a detection in the mixer code that the hw_volume is
> available or not. Maybe we can use this as well.

No, I don't think so. HW volume is a different thing. If a sink doesn't
have HW volume, then it will have SW volume. What we want to tell the
clients is that "this sink or this stream doesn't have volume at all". I
think a new flag for that is a fine solution.

I'm not sure if everyone agrees that the flags should change on the fly,
though, which will happen if a sink can disable volume whenever it
wants. An alternative is to put a new boolean variable to the
pa_sink_info struct. I don't care which solution is chosen.

At server side the situation is the same - shall we add a NOVOLUME flag
to sinks and make it possible to change the flags on the fly, or shall
we add a new "has_volume" boolean variable to pa_sink.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Great news that AC3 passthrough is working. Well done!

Are there any issues with AC3 encoding as I am using the A52 plugin from
Pulseaudio (without your patch) and required the following "hacks":
a. A rate converter in asoundrc:
# Rate Converter to 48kHz, needed for Pulseaudio it seems
pcm.Filter_
RateConvert {
type rate slave {
pcm "Filter_A52Encode" rate 48000
}
}
b. A timeout=0 in default.pa

load-module module-suspend-on-idle timeout=0 # timeout=0 required

Even with these "hacks", I found that sometimes I see:
I: module.c: Unloading "module-alsa-sink" (index: #4).
D: module-always-sink.c: Autoloading null-sink as no other sinks detected.
After I see that, the sink disappears and cannot be selected any more in sound
properties.

1. Does the ac3-iec958 profile resolve any of these issues?
2. Jack has ac3jack. What would be the pros and cons of doing the AC3 encoding
in Pulseaudio instead of in Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Sat, 2010-07-10 at 08:05 +0000, Michael Rans wrote:
> Even with these "hacks", I found that sometimes I see:
>
> I: module.c: Unloading "module-alsa-sink" (index: #4).
> D: module-always-sink.c: Autoloading null-sink as no other sinks
> detected.
>
>
> After I see that, the sink disappears and cannot be selected any more
> in sound properties.
>
> 1. Does the ac3-iec958 profile resolve any of these issues?

What's "the ac3-iec958 profile"? The iec958-ac3-surround-* mappings that
currently exist in pulseaudio use the a52 alsa plugin, which may or may
not work with Colin's patch[1]. (It didn't work for Colin.)

> 2. Jack has ac3jack. What would be the pros and cons of doing the AC3
> encoding in Pulseaudio instead of in Alsa?

I think it would make sense to do AC3 encoding in Pulseaudio, although
in theory I don't see what difference it would make. Maybe it's somehow
benefical to handle all the buffering inside Pulseaudio. If there are
timing related bugs in the a52 plugin, as Colin seems to think there
are, then it's also a matter of who volunteers first: a person who knows
how to fix the a52 plugin, or a person who knows how to hack AC3
encoding support into Pulseaudio.

[1] https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-June/007311.html

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Thanks for your reply both to my message and the bug I posted.

I tried Colin's patch, but it didn't work for me.

I tried the following evil hack in alsa-sink.c:
out_frames = snd_pcm_rewind(u->pcm_handle, (snd_pcm_uframes_t)
in_frames);
if (out_frames < 0) {
out_frames = -out_frames;
}
/* if ((out_frames = snd_pcm_rewind(u->pcm_handle, (snd_pcm_uframes_t)
in_frames)) < 0) {
pa_log("snd_pcm_rewind() failed: %s", pa_alsa_strerror((int)
out_frames));
if (try_recover(u, "process_rewind", out_frames) < 0)
return -1;
out_frames = 0;
}*/

The sound played but very very fast in Oolite, so I would say it almost worked.

I can't find any definition of snd_pcm_rewind() in the alsa-plugins source code.
Does this function call through to a function in the plugins?

I understand that there a function snd_pcm_hw_params_can_rewind which I would
guess should return false for AC3 encoding - is this called by Pulseaudio?

Cheers,
Mike





________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Further to my previous message, I tried:
// pa_sink_set_max_rewind(u->sink, u->hwbuf_size);
pa_sink_set_max_rewind(u->sink, 0);

That seemed to fix it, although I fear it will break any other Alsa sinks. Is
there a better way to implement this?

Interestingly, I then no longer need tiemout=0 here:
load-module module-suspend-on-idle

But I still need to go via the rate converter to the a52 encoder in asoundrc.

Cheers,
Mike





________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote:
> First this passthrough mode is only valid for S/PDIF and HDMI outputs.
> In both cases, the receiver may or may not support encoded content,
> and in the SPDIF case you have no way of querying what the receiver
> capabilities are. You absolutely do not want to send passthrough
> streams without making sure the configuration makes sense.
> So somehow user interaction is required to explicitly tell PulseAudio
> the receiver supports AC3/DTS passthrough. To be more self-explanatory
> we should have a check-box in pavucontrol than a different profile.
> I really did not want to switch configurations depending on the type
> of content, ALSA/iec958 accepts both.

I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.

Having thought this for a while, the only thing that really irritates me
in your design is that the semantics of the PA_SINK_PASSTHROUGH become
messy: the flag says that "in addition to normal PCM streams, this sink
supports also passthrough streams, except at times when there already
exist PCM streams, and btw, while a passthrough stream is playing, PCM
streams cease to be supported". I guess that's not a very practical
problem, though.

Ah, but now a better argument popped into my mind. If a sink can enter
the passthrough mode on the fly, then that has a consequence that
affects any application that is interested in sink volumes: whether a
sink has adjustable volume can change any time. That's not very nice.

> > Previously I claimed that since the the stream is compressed, we
> > inevitably will have to extend the code in pa_bytes_to_usec(), but I
> > realized now that as long as we pretend that the stream really is a
> > regular stereo stream, all calculations end up correct. Now the only
> > problem is that the user is given sort of wrong information, but I don't
> > think that's a big problem, so I agree with your approach of leaving the
> > sample spec alone and relying only on the sink and sink input flags. The
> > code can be improved later, if needed.
>
>
> > About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> > First, "non-audio" is not really correct, because the data is still
> > audio, but the main issue is the "iec958" part. There can potentially be
> > many formats that need to be passed through unchanged, so in the future
> > there could be need for PA_STREAM_NONAUDIO_FOO and
> > PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> > the format information - the format should have its own variable. Until
> > new formats are introduced, you can still rely on a single flag, though.
> > I propose that you just rename the flags:
> >
> > - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
> > - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
> > - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.
>
> I really don't think there are that many formats. The only use cases I
> can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
> audio. Adding flags on the sinks is no big deal.

Even if we have only two formats, iec958 and mp3, I don't see why the
sink flags would the proper place to specify the format. I believe most
of the passthrough related code is only interested in the fact that the
stream data shall not be touched. If there are multiple flags for all
the different passthrough formats, then all that code will have to check
for two flags instead of one.

> The real problem is at the pa_stream level. We don't want to have to
> extend the protocol several times. I added a flag but if we have more
> than one format we will need more room for subtypes. We should
> probably extend the buff_attr attributes for this?

I haven't though about this much, but I have a feeling that more complex
formats (like mp3) are going to need more metadata than currently
available (stuff like bitrate, CBR vs VBR etc.), and if support for
other codecs is going to be needed in the future, the set of metadata
items might vary between codecs. I wouldn't care about all that complex
stuff before it's implemented - in other words, I don't see it as a big
problem if the protocol will have to be extended multiple times for
different codecs. (Of course it would be nice to avoid that, but I
wouldn't trust at least myself to get it right at first try without
actually implementing the mp3 passthrough functionality at the same
time.)

> > I think the most natural place for input compatibility checking is in
> > the sink object. At least it achieves better encapsulation, because then
> > you don't need to poke the sink's "private-ish" data from outside the
> > sink object. That makes future changes easier to do.
>
> I disagree. I think you want a common logic in the core to make sure
> that things work the same way no matter what configuration you use.
> And its make sure we don't have to modify all existing sinks to
> perform the same checks.

There would of course be a standard implementation for sinks that don't
do any "strange" stuff. I thought individual sink implementations could
choose to amend the standard logic, but actually I'm not sure how it
could be done without duplicating code.

Giving it a second thought, the "can this sink input be connected to
this sink" question can be thought equally well as a method of sinks or
sink inputs, or even as a plain old independent function. So, doing it
like you do it in your patch is fine by me (just don't use "iec958"
where the logic isn't really bound to the exact format).

> > The NOVOLUME flags can be exported to clients, so they can choose to not
> > show any volume controls. Legacy clients should get the
> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> > sinks that have the NOVOLUME flag.
>
> Yes the volume needs more work. I don't really understand all this
> code through, so for now I disabled the set-volume() routines without
> notifying the client. You end-up in the situation where pavucontrol
> can change the volume but nothing happens, this is not user-friendly.
> Is this NOVOLUME flag an existing one, or something that would need to be added?

It needs to be added.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I agree that it's not really a good solution to require the user to
> change the card profile manually to enable passthrough via spdif. But as
> I said, a separate module could take care switching between the profiles
> as needed.

I don't understand your proposal. What do you mean by separate
'module' and how would this work with the current mixer profiles?

> Having thought this for a while, the only thing that really irritates me
> in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> messy: the flag says that "in addition to normal PCM streams, this sink
> supports also passthrough streams, except at times when there already
> exist PCM streams, and btw, while a passthrough stream is playing, PCM
> streams cease to be supported". I guess that's not a very practical
> problem, though.

It's not really my design, it's just how SPDIF/HDMI work...

> Ah, but now a better argument popped into my mind. If a sink can enter
> the passthrough mode on the fly, then that has a consequence that
> affects any application that is interested in sink volumes: whether a
> sink has adjustable volume can change any time. That's not very nice.

Duh? If we fixed the volume stuff so that that the volume control app
disables its sliders when passthrough AC3 is enabled, what would be
the issue. This is how VLC works, when you stream AC3 data the volume
control is no longer enabled.

> Even if we have only two formats, iec958 and mp3, I don't see why the
> sink flags would the proper place to specify the format. I believe most
> of the passthrough related code is only interested in the fact that the
> stream data shall not be touched. If there are multiple flags for all
> the different passthrough formats, then all that code will have to check
> for two flags instead of one.

I guess we could have a two-step process, where you first detect if
the sink and sink-input have support for PASSTHROUGH, and then in a
second step you verify that the 'subtype' (iec958 or mp3) is
compatible. The logic for rejecting connections is the same... You
only need one last step to make sure types are compatible.

> There would of course be a standard implementation for sinks that don't
> do any "strange" stuff. I thought individual sink implementations could
> choose to amend the standard logic, but actually I'm not sure how it
> could be done without duplicating code.
>
> Giving it a second thought, the "can this sink input be connected to
> this sink" question can be thought equally well as a method of sinks or
> sink inputs, or even as a plain old independent function. So, doing it
> like you do it in your patch is fine by me (just don't use "iec958"
> where the logic isn't really bound to the exact format).

As I said above, we can have a first pass implemented in the core that
checks things are fine, then a second pass implemented by sinks who
support passthrough mode to check fine-grained compatibility.

>> > The NOVOLUME flags can be exported to clients, so they can choose to not
>> > show any volume controls. Legacy clients should get the
>> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
>> > sinks that have the NOVOLUME flag.
>>
>> Yes the volume needs more work. I don't really understand all this
>> code through, so for now I disabled the set-volume() routines without
>> notifying the client. You end-up in the situation where pavucontrol
>> can change the volume but nothing happens, this is not user-friendly.
>> Is this NOVOLUME flag an existing one, or something that would need to be added?
>
> It needs to be added.

There's already a detection in the mixer code that the hw_volume is
available or not. Maybe we can use this as well.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or
is someone actively looking at developing it?
2. I think that encoding needs to be considered as part of the design ie. the
possibility of AC3 or MP3 encoding before output to SPDIF.

Perhaps you're already past this point, but there is an Alsa utility iecset
which returns (and can set) whether raw data or PCM is being passed to SPDIF. So
presumably the Pulseaudio passthrough for Alsa just needs to call the same
function that utility does.

Can someone point me to any design and API docs for Pulseaudio as I'm interested
in learning where and how it connects to Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > 1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point
> only or is someone actively looking at developing it?

AC3 passthrough works (see patches at start of thread). That said
there are still some opens and feedback is still welcome. I guess this
will be part of Meego at some point, but since there''s nothing hw
specific the discussion takes place in the open.

> 2. I think that encoding needs to be considered as part of the design ie.
> the possibility of AC3 or MP3 encoding before output to SPDIF.

AC3 encoding can be done by selecting the relevant profile
(ac3-iec958). The encoding takes place in alsa-lib a52 plugin. I
initially removed these profiles but took some flak for it, apparently
some people encode their multichannel streams prior to SPDIF
transmission.
I am afraid MP3 encoding in PulseAudio doesn't make sense, not
supported either by SPDIF or HDMI. And for BT use cases, you might as
well encode in SBC if you have PCM in the first place.

> Perhaps you're already past this point, but there is an Alsa utility iecset
> which returns (and can set) whether raw data or PCM is being passed to
> SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call
> the same function that utility does.

iecset sets the AES0-3 bytes, but does not handle actual data
formatting which is done by the gstreamer ac3iec958 element and by the
alsa-lib iec958 plugin. For now I don't even bother to set these bits,
they are so unreliable that receivers usually ignore them.

> Can someone point me to any design and API docs for Pulseaudio as I'm
> interested in learning where and how it connects to Alsa?

No real docs. See the code in src/modules/alsa. Only took me a year to
figure things out :-(
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Fri, 2010-07-09 at 10:51 -0500, pl bossart wrote:
> > I agree that it's not really a good solution to require the user to
> > change the card profile manually to enable passthrough via spdif. But as
> > I said, a separate module could take care switching between the profiles
> > as needed.
>
> I don't understand your proposal. What do you mean by separate
> 'module' and how would this work with the current mixer profiles?

PA_CORE_HOOK_SINK_INPUT_NEW is fired at the beginning of
pa_sink_input_new(). A module can connect to that hook and detect that
"ah, data->flags contains PA_SINK_INPUT_PASSTHROUGH, and data->sink is
NULL, I'll make sure that the passthrough sink is available".

Configuring (automatically) such module would need some extensions to
the card profile code so that this new module could figure out what
needs to be done in order to "make sure that the passthrough sink is
available". My feeling is/was that it's probably doable without too much
difficulty, and that's about as far as I thought about it.

Now, what if data->sink is not NULL? That means that when the client
created the stream, the correct profile was already activated. Or,
alternatively, data->sink points to some "ghost" of a currently
non-existing sink that can, however, be "made real" automatically
somehow. This latter scenario refers to functionality that doesn't
currently exist. Implementing such functionality would require big
changes to a lot of stuff.

I'm starting to like your approach more and more.

> > Having thought this for a while, the only thing that really irritates me
> > in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> > messy: the flag says that "in addition to normal PCM streams, this sink
> > supports also passthrough streams, except at times when there already
> > exist PCM streams, and btw, while a passthrough stream is playing, PCM
> > streams cease to be supported". I guess that's not a very practical
> > problem, though.
>
> It's not really my design, it's just how SPDIF/HDMI work...

Well, when defining the semantics of PA_SINK_PASSTHROUGH you're free to
choose between "combined PCM and passthrough" or "passthrough only".
Either can be made to work with spdif/hdmi. And I think it's not really
specific to spdif/hdmi - both semantics can be used with any passthrough
sink. For example, using your semantics, an A2DP sink can switch between
real-time SBC encoding and passthrough MP3 on the fly similarly how an
spdif sink can change between PCM and passthrough operation. The only
case where the "combined" semantics wouldn't work is when the sink just
plain can't work in any other mode than passthrough. I think it's quite
improbable that we'll ever see such sink.

> > Ah, but now a better argument popped into my mind. If a sink can enter
> > the passthrough mode on the fly, then that has a consequence that
> > affects any application that is interested in sink volumes: whether a
> > sink has adjustable volume can change any time. That's not very nice.
>
> Duh? If we fixed the volume stuff so that that the volume control app
> disables its sliders when passthrough AC3 is enabled, what would be
> the issue. This is how VLC works, when you stream AC3 data the volume
> control is no longer enabled.

What I had in mind was that if changing between PCM and passthrough
modes would require changing profiles, then clients wouldn't need to be
prepared to disable and enable volume control for a sink on the fly.
They would only need to check whether a sink has volume when they
initially create the widget for the sink.

If volume can be disabled on the fly, that pushes more complexity to the
clients, which is not good. But actually I think we'll have to do this,
since the profile-switching module seems impractical.

It seems like all my ideas were crap :)

> > Even if we have only two formats, iec958 and mp3, I don't see why the
> > sink flags would the proper place to specify the format. I believe most
> > of the passthrough related code is only interested in the fact that the
> > stream data shall not be touched. If there are multiple flags for all
> > the different passthrough formats, then all that code will have to check
> > for two flags instead of one.
>
> I guess we could have a two-step process, where you first detect if
> the sink and sink-input have support for PASSTHROUGH, and then in a
> second step you verify that the 'subtype' (iec958 or mp3) is
> compatible. The logic for rejecting connections is the same... You
> only need one last step to make sure types are compatible.
>
> > There would of course be a standard implementation for sinks that don't
> > do any "strange" stuff. I thought individual sink implementations could
> > choose to amend the standard logic, but actually I'm not sure how it
> > could be done without duplicating code.
> >
> > Giving it a second thought, the "can this sink input be connected to
> > this sink" question can be thought equally well as a method of sinks or
> > sink inputs, or even as a plain old independent function. So, doing it
> > like you do it in your patch is fine by me (just don't use "iec958"
> > where the logic isn't really bound to the exact format).
>
> As I said above, we can have a first pass implemented in the core that
> checks things are fine, then a second pass implemented by sinks who
> support passthrough mode to check fine-grained compatibility.

I think I'd just put a new variable in pa_sink and pa_sink_input (or
maybe pa_sample_spec?) that would store the codec information, and do
all checking in the core in one place.

> >> > The NOVOLUME flags can be exported to clients, so they can choose to not
> >> > show any volume controls. Legacy clients should get the
> >> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> >> > sinks that have the NOVOLUME flag.
> >>
> >> Yes the volume needs more work. I don't really understand all this
> >> code through, so for now I disabled the set-volume() routines without
> >> notifying the client. You end-up in the situation where pavucontrol
> >> can change the volume but nothing happens, this is not user-friendly.
> >> Is this NOVOLUME flag an existing one, or something that would need to be added?
> >
> > It needs to be added.
>
> There's already a detection in the mixer code that the hw_volume is
> available or not. Maybe we can use this as well.

No, I don't think so. HW volume is a different thing. If a sink doesn't
have HW volume, then it will have SW volume. What we want to tell the
clients is that "this sink or this stream doesn't have volume at all". I
think a new flag for that is a fine solution.

I'm not sure if everyone agrees that the flags should change on the fly,
though, which will happen if a sink can disable volume whenever it
wants. An alternative is to put a new boolean variable to the
pa_sink_info struct. I don't care which solution is chosen.

At server side the situation is the same - shall we add a NOVOLUME flag
to sinks and make it possible to change the flags on the fly, or shall
we add a new "has_volume" boolean variable to pa_sink.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Great news that AC3 passthrough is working. Well done!

Are there any issues with AC3 encoding as I am using the A52 plugin from
Pulseaudio (without your patch) and required the following "hacks":
a. A rate converter in asoundrc:
# Rate Converter to 48kHz, needed for Pulseaudio it seems
pcm.Filter_
RateConvert {
type rate slave {
pcm "Filter_A52Encode" rate 48000
}
}
b. A timeout=0 in default.pa

load-module module-suspend-on-idle timeout=0 # timeout=0 required

Even with these "hacks", I found that sometimes I see:
I: module.c: Unloading "module-alsa-sink" (index: #4).
D: module-always-sink.c: Autoloading null-sink as no other sinks detected.
After I see that, the sink disappears and cannot be selected any more in sound
properties.

1. Does the ac3-iec958 profile resolve any of these issues?
2. Jack has ac3jack. What would be the pros and cons of doing the AC3 encoding
in Pulseaudio instead of in Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Sat, 2010-07-10 at 08:05 +0000, Michael Rans wrote:
> Even with these "hacks", I found that sometimes I see:
>
> I: module.c: Unloading "module-alsa-sink" (index: #4).
> D: module-always-sink.c: Autoloading null-sink as no other sinks
> detected.
>
>
> After I see that, the sink disappears and cannot be selected any more
> in sound properties.
>
> 1. Does the ac3-iec958 profile resolve any of these issues?

What's "the ac3-iec958 profile"? The iec958-ac3-surround-* mappings that
currently exist in pulseaudio use the a52 alsa plugin, which may or may
not work with Colin's patch[1]. (It didn't work for Colin.)

> 2. Jack has ac3jack. What would be the pros and cons of doing the AC3
> encoding in Pulseaudio instead of in Alsa?

I think it would make sense to do AC3 encoding in Pulseaudio, although
in theory I don't see what difference it would make. Maybe it's somehow
benefical to handle all the buffering inside Pulseaudio. If there are
timing related bugs in the a52 plugin, as Colin seems to think there
are, then it's also a matter of who volunteers first: a person who knows
how to fix the a52 plugin, or a person who knows how to hack AC3
encoding support into Pulseaudio.

[1] https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-June/007311.html

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Thanks for your reply both to my message and the bug I posted.

I tried Colin's patch, but it didn't work for me.

I tried the following evil hack in alsa-sink.c:
out_frames = snd_pcm_rewind(u->pcm_handle, (snd_pcm_uframes_t)
in_frames);
if (out_frames < 0) {
out_frames = -out_frames;
}
/* if ((out_frames = snd_pcm_rewind(u->pcm_handle, (snd_pcm_uframes_t)
in_frames)) < 0) {
pa_log("snd_pcm_rewind() failed: %s", pa_alsa_strerror((int)
out_frames));
if (try_recover(u, "process_rewind", out_frames) < 0)
return -1;
out_frames = 0;
}*/

The sound played but very very fast in Oolite, so I would say it almost worked.

I can't find any definition of snd_pcm_rewind() in the alsa-plugins source code.
Does this function call through to a function in the plugins?

I understand that there a function snd_pcm_hw_params_can_rewind which I would
guess should return false for AC3 encoding - is this called by Pulseaudio?

Cheers,
Mike





________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Further to my previous message, I tried:
// pa_sink_set_max_rewind(u->sink, u->hwbuf_size);
pa_sink_set_max_rewind(u->sink, 0);

That seemed to fix it, although I fear it will break any other Alsa sinks. Is
there a better way to implement this?

Interestingly, I then no longer need tiemout=0 here:
load-module module-suspend-on-idle

But I still need to go via the rate converter to the a52 encoder in asoundrc.

Cheers,
Mike





________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > But I still need to go via the rate converter to the a52 encoder in
> asoundrc.

Have you set the default sink frequency to 48kHz in
/usr/etc/pulse/daemon.conf? This should handle resampling in
PulseAudio.
Still not clear why rewind doesn't work.
- Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote:
> First this passthrough mode is only valid for S/PDIF and HDMI outputs.
> In both cases, the receiver may or may not support encoded content,
> and in the SPDIF case you have no way of querying what the receiver
> capabilities are. You absolutely do not want to send passthrough
> streams without making sure the configuration makes sense.
> So somehow user interaction is required to explicitly tell PulseAudio
> the receiver supports AC3/DTS passthrough. To be more self-explanatory
> we should have a check-box in pavucontrol than a different profile.
> I really did not want to switch configurations depending on the type
> of content, ALSA/iec958 accepts both.

I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.

Having thought this for a while, the only thing that really irritates me
in your design is that the semantics of the PA_SINK_PASSTHROUGH become
messy: the flag says that "in addition to normal PCM streams, this sink
supports also passthrough streams, except at times when there already
exist PCM streams, and btw, while a passthrough stream is playing, PCM
streams cease to be supported". I guess that's not a very practical
problem, though.

Ah, but now a better argument popped into my mind. If a sink can enter
the passthrough mode on the fly, then that has a consequence that
affects any application that is interested in sink volumes: whether a
sink has adjustable volume can change any time. That's not very nice.

> > Previously I claimed that since the the stream is compressed, we
> > inevitably will have to extend the code in pa_bytes_to_usec(), but I
> > realized now that as long as we pretend that the stream really is a
> > regular stereo stream, all calculations end up correct. Now the only
> > problem is that the user is given sort of wrong information, but I don't
> > think that's a big problem, so I agree with your approach of leaving the
> > sample spec alone and relying only on the sink and sink input flags. The
> > code can be improved later, if needed.
>
>
> > About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> > First, "non-audio" is not really correct, because the data is still
> > audio, but the main issue is the "iec958" part. There can potentially be
> > many formats that need to be passed through unchanged, so in the future
> > there could be need for PA_STREAM_NONAUDIO_FOO and
> > PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> > the format information - the format should have its own variable. Until
> > new formats are introduced, you can still rely on a single flag, though.
> > I propose that you just rename the flags:
> >
> > - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
> > - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
> > - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.
>
> I really don't think there are that many formats. The only use cases I
> can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
> audio. Adding flags on the sinks is no big deal.

Even if we have only two formats, iec958 and mp3, I don't see why the
sink flags would the proper place to specify the format. I believe most
of the passthrough related code is only interested in the fact that the
stream data shall not be touched. If there are multiple flags for all
the different passthrough formats, then all that code will have to check
for two flags instead of one.

> The real problem is at the pa_stream level. We don't want to have to
> extend the protocol several times. I added a flag but if we have more
> than one format we will need more room for subtypes. We should
> probably extend the buff_attr attributes for this?

I haven't though about this much, but I have a feeling that more complex
formats (like mp3) are going to need more metadata than currently
available (stuff like bitrate, CBR vs VBR etc.), and if support for
other codecs is going to be needed in the future, the set of metadata
items might vary between codecs. I wouldn't care about all that complex
stuff before it's implemented - in other words, I don't see it as a big
problem if the protocol will have to be extended multiple times for
different codecs. (Of course it would be nice to avoid that, but I
wouldn't trust at least myself to get it right at first try without
actually implementing the mp3 passthrough functionality at the same
time.)

> > I think the most natural place for input compatibility checking is in
> > the sink object. At least it achieves better encapsulation, because then
> > you don't need to poke the sink's "private-ish" data from outside the
> > sink object. That makes future changes easier to do.
>
> I disagree. I think you want a common logic in the core to make sure
> that things work the same way no matter what configuration you use.
> And its make sure we don't have to modify all existing sinks to
> perform the same checks.

There would of course be a standard implementation for sinks that don't
do any "strange" stuff. I thought individual sink implementations could
choose to amend the standard logic, but actually I'm not sure how it
could be done without duplicating code.

Giving it a second thought, the "can this sink input be connected to
this sink" question can be thought equally well as a method of sinks or
sink inputs, or even as a plain old independent function. So, doing it
like you do it in your patch is fine by me (just don't use "iec958"
where the logic isn't really bound to the exact format).

> > The NOVOLUME flags can be exported to clients, so they can choose to not
> > show any volume controls. Legacy clients should get the
> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> > sinks that have the NOVOLUME flag.
>
> Yes the volume needs more work. I don't really understand all this
> code through, so for now I disabled the set-volume() routines without
> notifying the client. You end-up in the situation where pavucontrol
> can change the volume but nothing happens, this is not user-friendly.
> Is this NOVOLUME flag an existing one, or something that would need to be added?

It needs to be added.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I agree that it's not really a good solution to require the user to
> change the card profile manually to enable passthrough via spdif. But as
> I said, a separate module could take care switching between the profiles
> as needed.

I don't understand your proposal. What do you mean by separate
'module' and how would this work with the current mixer profiles?

> Having thought this for a while, the only thing that really irritates me
> in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> messy: the flag says that "in addition to normal PCM streams, this sink
> supports also passthrough streams, except at times when there already
> exist PCM streams, and btw, while a passthrough stream is playing, PCM
> streams cease to be supported". I guess that's not a very practical
> problem, though.

It's not really my design, it's just how SPDIF/HDMI work...

> Ah, but now a better argument popped into my mind. If a sink can enter
> the passthrough mode on the fly, then that has a consequence that
> affects any application that is interested in sink volumes: whether a
> sink has adjustable volume can change any time. That's not very nice.

Duh? If we fixed the volume stuff so that that the volume control app
disables its sliders when passthrough AC3 is enabled, what would be
the issue. This is how VLC works, when you stream AC3 data the volume
control is no longer enabled.

> Even if we have only two formats, iec958 and mp3, I don't see why the
> sink flags would the proper place to specify the format. I believe most
> of the passthrough related code is only interested in the fact that the
> stream data shall not be touched. If there are multiple flags for all
> the different passthrough formats, then all that code will have to check
> for two flags instead of one.

I guess we could have a two-step process, where you first detect if
the sink and sink-input have support for PASSTHROUGH, and then in a
second step you verify that the 'subtype' (iec958 or mp3) is
compatible. The logic for rejecting connections is the same... You
only need one last step to make sure types are compatible.

> There would of course be a standard implementation for sinks that don't
> do any "strange" stuff. I thought individual sink implementations could
> choose to amend the standard logic, but actually I'm not sure how it
> could be done without duplicating code.
>
> Giving it a second thought, the "can this sink input be connected to
> this sink" question can be thought equally well as a method of sinks or
> sink inputs, or even as a plain old independent function. So, doing it
> like you do it in your patch is fine by me (just don't use "iec958"
> where the logic isn't really bound to the exact format).

As I said above, we can have a first pass implemented in the core that
checks things are fine, then a second pass implemented by sinks who
support passthrough mode to check fine-grained compatibility.

>> > The NOVOLUME flags can be exported to clients, so they can choose to not
>> > show any volume controls. Legacy clients should get the
>> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
>> > sinks that have the NOVOLUME flag.
>>
>> Yes the volume needs more work. I don't really understand all this
>> code through, so for now I disabled the set-volume() routines without
>> notifying the client. You end-up in the situation where pavucontrol
>> can change the volume but nothing happens, this is not user-friendly.
>> Is this NOVOLUME flag an existing one, or something that would need to be added?
>
> It needs to be added.

There's already a detection in the mixer code that the hw_volume is
available or not. Maybe we can use this as well.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or
is someone actively looking at developing it?
2. I think that encoding needs to be considered as part of the design ie. the
possibility of AC3 or MP3 encoding before output to SPDIF.

Perhaps you're already past this point, but there is an Alsa utility iecset
which returns (and can set) whether raw data or PCM is being passed to SPDIF. So
presumably the Pulseaudio passthrough for Alsa just needs to call the same
function that utility does.

Can someone point me to any design and API docs for Pulseaudio as I'm interested
in learning where and how it connects to Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > 1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point
> only or is someone actively looking at developing it?

AC3 passthrough works (see patches at start of thread). That said
there are still some opens and feedback is still welcome. I guess this
will be part of Meego at some point, but since there''s nothing hw
specific the discussion takes place in the open.

> 2. I think that encoding needs to be considered as part of the design ie.
> the possibility of AC3 or MP3 encoding before output to SPDIF.

AC3 encoding can be done by selecting the relevant profile
(ac3-iec958). The encoding takes place in alsa-lib a52 plugin. I
initially removed these profiles but took some flak for it, apparently
some people encode their multichannel streams prior to SPDIF
transmission.
I am afraid MP3 encoding in PulseAudio doesn't make sense, not
supported either by SPDIF or HDMI. And for BT use cases, you might as
well encode in SBC if you have PCM in the first place.

> Perhaps you're already past this point, but there is an Alsa utility iecset
> which returns (and can set) whether raw data or PCM is being passed to
> SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call
> the same function that utility does.

iecset sets the AES0-3 bytes, but does not handle actual data
formatting which is done by the gstreamer ac3iec958 element and by the
alsa-lib iec958 plugin. For now I don't even bother to set these bits,
they are so unreliable that receivers usually ignore them.

> Can someone point me to any design and API docs for Pulseaudio as I'm
> interested in learning where and how it connects to Alsa?

No real docs. See the code in src/modules/alsa. Only took me a year to
figure things out :-(
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Fri, 2010-07-09 at 10:51 -0500, pl bossart wrote:
> > I agree that it's not really a good solution to require the user to
> > change the card profile manually to enable passthrough via spdif. But as
> > I said, a separate module could take care switching between the profiles
> > as needed.
>
> I don't understand your proposal. What do you mean by separate
> 'module' and how would this work with the current mixer profiles?

PA_CORE_HOOK_SINK_INPUT_NEW is fired at the beginning of
pa_sink_input_new(). A module can connect to that hook and detect that
"ah, data->flags contains PA_SINK_INPUT_PASSTHROUGH, and data->sink is
NULL, I'll make sure that the passthrough sink is available".

Configuring (automatically) such module would need some extensions to
the card profile code so that this new module could figure out what
needs to be done in order to "make sure that the passthrough sink is
available". My feeling is/was that it's probably doable without too much
difficulty, and that's about as far as I thought about it.

Now, what if data->sink is not NULL? That means that when the client
created the stream, the correct profile was already activated. Or,
alternatively, data->sink points to some "ghost" of a currently
non-existing sink that can, however, be "made real" automatically
somehow. This latter scenario refers to functionality that doesn't
currently exist. Implementing such functionality would require big
changes to a lot of stuff.

I'm starting to like your approach more and more.

> > Having thought this for a while, the only thing that really irritates me
> > in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> > messy: the flag says that "in addition to normal PCM streams, this sink
> > supports also passthrough streams, except at times when there already
> > exist PCM streams, and btw, while a passthrough stream is playing, PCM
> > streams cease to be supported". I guess that's not a very practical
> > problem, though.
>
> It's not really my design, it's just how SPDIF/HDMI work...

Well, when defining the semantics of PA_SINK_PASSTHROUGH you're free to
choose between "combined PCM and passthrough" or "passthrough only".
Either can be made to work with spdif/hdmi. And I think it's not really
specific to spdif/hdmi - both semantics can be used with any passthrough
sink. For example, using your semantics, an A2DP sink can switch between
real-time SBC encoding and passthrough MP3 on the fly similarly how an
spdif sink can change between PCM and passthrough operation. The only
case where the "combined" semantics wouldn't work is when the sink just
plain can't work in any other mode than passthrough. I think it's quite
improbable that we'll ever see such sink.

> > Ah, but now a better argument popped into my mind. If a sink can enter
> > the passthrough mode on the fly, then that has a consequence that
> > affects any application that is interested in sink volumes: whether a
> > sink has adjustable volume can change any time. That's not very nice.
>
> Duh? If we fixed the volume stuff so that that the volume control app
> disables its sliders when passthrough AC3 is enabled, what would be
> the issue. This is how VLC works, when you stream AC3 data the volume
> control is no longer enabled.

What I had in mind was that if changing between PCM and passthrough
modes would require changing profiles, then clients wouldn't need to be
prepared to disable and enable volume control for a sink on the fly.
They would only need to check whether a sink has volume when they
initially create the widget for the sink.

If volume can be disabled on the fly, that pushes more complexity to the
clients, which is not good. But actually I think we'll have to do this,
since the profile-switching module seems impractical.

It seems like all my ideas were crap :)

> > Even if we have only two formats, iec958 and mp3, I don't see why the
> > sink flags would the proper place to specify the format. I believe most
> > of the passthrough related code is only interested in the fact that the
> > stream data shall not be touched. If there are multiple flags for all
> > the different passthrough formats, then all that code will have to check
> > for two flags instead of one.
>
> I guess we could have a two-step process, where you first detect if
> the sink and sink-input have support for PASSTHROUGH, and then in a
> second step you verify that the 'subtype' (iec958 or mp3) is
> compatible. The logic for rejecting connections is the same... You
> only need one last step to make sure types are compatible.
>
> > There would of course be a standard implementation for sinks that don't
> > do any "strange" stuff. I thought individual sink implementations could
> > choose to amend the standard logic, but actually I'm not sure how it
> > could be done without duplicating code.
> >
> > Giving it a second thought, the "can this sink input be connected to
> > this sink" question can be thought equally well as a method of sinks or
> > sink inputs, or even as a plain old independent function. So, doing it
> > like you do it in your patch is fine by me (just don't use "iec958"
> > where the logic isn't really bound to the exact format).
>
> As I said above, we can have a first pass implemented in the core that
> checks things are fine, then a second pass implemented by sinks who
> support passthrough mode to check fine-grained compatibility.

I think I'd just put a new variable in pa_sink and pa_sink_input (or
maybe pa_sample_spec?) that would store the codec information, and do
all checking in the core in one place.

> >> > The NOVOLUME flags can be exported to clients, so they can choose to not
> >> > show any volume controls. Legacy clients should get the
> >> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> >> > sinks that have the NOVOLUME flag.
> >>
> >> Yes the volume needs more work. I don't really understand all this
> >> code through, so for now I disabled the set-volume() routines without
> >> notifying the client. You end-up in the situation where pavucontrol
> >> can change the volume but nothing happens, this is not user-friendly.
> >> Is this NOVOLUME flag an existing one, or something that would need to be added?
> >
> > It needs to be added.
>
> There's already a detection in the mixer code that the hw_volume is
> available or not. Maybe we can use this as well.

No, I don't think so. HW volume is a different thing. If a sink doesn't
have HW volume, then it will have SW volume. What we want to tell the
clients is that "this sink or this stream doesn't have volume at all". I
think a new flag for that is a fine solution.

I'm not sure if everyone agrees that the flags should change on the fly,
though, which will happen if a sink can disable volume whenever it
wants. An alternative is to put a new boolean variable to the
pa_sink_info struct. I don't care which solution is chosen.

At server side the situation is the same - shall we add a NOVOLUME flag
to sinks and make it possible to change the flags on the fly, or shall
we add a new "has_volume" boolean variable to pa_sink.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Great news that AC3 passthrough is working. Well done!

Are there any issues with AC3 encoding as I am using the A52 plugin from
Pulseaudio (without your patch) and required the following "hacks":
a. A rate converter in asoundrc:
# Rate Converter to 48kHz, needed for Pulseaudio it seems
pcm.Filter_
RateConvert {
type rate slave {
pcm "Filter_A52Encode" rate 48000
}
}
b. A timeout=0 in default.pa

load-module module-suspend-on-idle timeout=0 # timeout=0 required

Even with these "hacks", I found that sometimes I see:
I: module.c: Unloading "module-alsa-sink" (index: #4).
D: module-always-sink.c: Autoloading null-sink as no other sinks detected.
After I see that, the sink disappears and cannot be selected any more in sound
properties.

1. Does the ac3-iec958 profile resolve any of these issues?
2. Jack has ac3jack. What would be the pros and cons of doing the AC3 encoding
in Pulseaudio instead of in Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Sat, 2010-07-10 at 08:05 +0000, Michael Rans wrote:
> Even with these "hacks", I found that sometimes I see:
>
> I: module.c: Unloading "module-alsa-sink" (index: #4).
> D: module-always-sink.c: Autoloading null-sink as no other sinks
> detected.
>
>
> After I see that, the sink disappears and cannot be selected any more
> in sound properties.
>
> 1. Does the ac3-iec958 profile resolve any of these issues?

What's "the ac3-iec958 profile"? The iec958-ac3-surround-* mappings that
currently exist in pulseaudio use the a52 alsa plugin, which may or may
not work with Colin's patch[1]. (It didn't work for Colin.)

> 2. Jack has ac3jack. What would be the pros and cons of doing the AC3
> encoding in Pulseaudio instead of in Alsa?

I think it would make sense to do AC3 encoding in Pulseaudio, although
in theory I don't see what difference it would make. Maybe it's somehow
benefical to handle all the buffering inside Pulseaudio. If there are
timing related bugs in the a52 plugin, as Colin seems to think there
are, then it's also a matter of who volunteers first: a person who knows
how to fix the a52 plugin, or a person who knows how to hack AC3
encoding support into Pulseaudio.

[1] https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-June/007311.html

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Thanks for your reply both to my message and the bug I posted.

I tried Colin's patch, but it didn't work for me.

I tried the following evil hack in alsa-sink.c:
out_frames = snd_pcm_rewind(u->pcm_handle, (snd_pcm_uframes_t)
in_frames);
if (out_frames < 0) {
out_frames = -out_frames;
}
/* if ((out_frames = snd_pcm_rewind(u->pcm_handle, (snd_pcm_uframes_t)
in_frames)) < 0) {
pa_log("snd_pcm_rewind() failed: %s", pa_alsa_strerror((int)
out_frames));
if (try_recover(u, "process_rewind", out_frames) < 0)
return -1;
out_frames = 0;
}*/

The sound played but very very fast in Oolite, so I would say it almost worked.

I can't find any definition of snd_pcm_rewind() in the alsa-plugins source code.
Does this function call through to a function in the plugins?

I understand that there a function snd_pcm_hw_params_can_rewind which I would
guess should return false for AC3 encoding - is this called by Pulseaudio?

Cheers,
Mike





________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Further to my previous message, I tried:
// pa_sink_set_max_rewind(u->sink, u->hwbuf_size);
pa_sink_set_max_rewind(u->sink, 0);

That seemed to fix it, although I fear it will break any other Alsa sinks. Is
there a better way to implement this?

Interestingly, I then no longer need tiemout=0 here:
load-module module-suspend-on-idle

But I still need to go via the rate converter to the a52 encoder in asoundrc.

Cheers,
Mike





________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > But I still need to go via the rate converter to the a52 encoder in
> asoundrc.

Have you set the default sink frequency to 48kHz in
/usr/etc/pulse/daemon.conf? This should handle resampling in
PulseAudio.
Still not clear why rewind doesn't work.
- Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. My default.pa line has rate set at 48000 which I guess would take precedence:
load-module module-alsa-sink device=Filter_RateConvert rate=48000
sink_properties=device.description=SPDIF sink_name=SPDIF)

But just in case, I tried changing default-sample-rate = 48000 in daemon.conf.

The error I got was:

D: alsa-sink.c: snd_pcm_mmap_commit: Resource temporarily unavailable
E: alsa-sink.c: Assertion 'err != -11' failed at modules/alsa/alsa-sink.c:395,
function try_recover(). Aborting.

BTW, I got the setup using a rate converter from here:
http://www.johannes-bauer.com/linux/dolby/?menuid=3 where this chap says "# Rate
Converter to 48kHz, needed for some applications" in his advanced set up. He
didn't mention Pulseaudio, but it seems to do the trick.

Regarding AC3 encoding in Pulseaudio - it would be better because at the moment
switching between stereo and A52 is not possible (ie. I cannot have both these
lines in default.pa:
load-module module-alsa-sink device=Filter_RateConvert rate=48000
sink_properties=device.description=AC3 sink_name=AC3
load-module module-alsa-sink device=ALC889A_Digital
sink_properties=device.description=SPDIF sink_name=SPDIF

Presumably the SPDIF out is locked by one of them, then the other fails. With
ac3 encoding in Pulseaudio, this would be switchable without editing any files.

Cheers,
Mike






________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote:
> here's a first work-in-progress set of patches. I managed to route
> iec958 formatted data through PulseAudio, works fine but there's still
> a lot to do.

Sounds very good! Thanks for your work!

> There's some logic to prevent silly connections but
> still allow for the same use cases as before:
> you can still mix and play PCM streams on a passthrough output,
> however you cannot connect nonaudio data to a
> regular sink, and likewise if a sink has already a connection you can
> only connect if both the existing inputs and the new one are PCM.
> Volume control is disabled only when a nonaudio stream is connected.

So, do you think that if the card profile is set to Digital Passthrough
(IEC958), the sink should still accept normal PCM streams? I don't think
that's a good idea. You apparently do, and I'm not sure I'm able to
convince you otherwise, but I'll try.

In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
used both for exclusive passthrough streams and for normal streams. Are
you sure we can keep that promise for all future passthrough sinks too?
It would be cleaner to have strict separation between passthrough sinks
and non-passthrough sinks. I admit that your approach makes it much
easier for the user to switch between passthrough and non-passthrough
content, but that effect could also be achieved with a separate module
that changes the card profile whenever a passthrough stream is being
created.

> I still have to do some work on sample-rate and channel map
> adaptation, but comments are welcome at this point.

Ok, I'll comment.

> +[Element IEC958]
> +switch = mute

What if this element doesn't exist? Or is it guaranteed to exist? If it
doesn't exist, then PA will use software muting, i.e. feeding zeroes to
the device. I don't think that's good. A stream of zeroes is not a valid
iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
streams. Or is alsa capable of switching between passthrough and PCM
modes on the fly just by inspecting the data?

> @@ -163,6 +163,7 @@ struct pa_alsa_path {
> pa_bool_t has_mute:1;
> pa_bool_t has_volume:1;
> pa_bool_t has_dB:1;
> + pa_bool_t is_passthrough:1;
>
> long min_volume, max_volume;
> double min_dB, max_dB;

is_passthrough doesn't seem to be set anywhere.

Other comments:

Previously I claimed that since the the stream is compressed, we
inevitably will have to extend the code in pa_bytes_to_usec(), but I
realized now that as long as we pretend that the stream really is a
regular stereo stream, all calculations end up correct. Now the only
problem is that the user is given sort of wrong information, but I don't
think that's a big problem, so I agree with your approach of leaving the
sample spec alone and relying only on the sink and sink input flags. The
code can be improved later, if needed.

About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
First, "non-audio" is not really correct, because the data is still
audio, but the main issue is the "iec958" part. There can potentially be
many formats that need to be passed through unchanged, so in the future
there could be need for PA_STREAM_NONAUDIO_FOO and
PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
the format information - the format should have its own variable. Until
new formats are introduced, you can still rely on a single flag, though.
I propose that you just rename the flags:

- PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
- PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
- PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

You can put in the client documentation that if the
PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed
to be iec958 formatted, and the sample spec must be stereo s16le with
sample rate of 32000, 44100 or 48000 Hz. In the future there may be more
options.

I still hold on to a couple of my previous suggestions: create
pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs.

I think the most natural place for input compatibility checking is in
the sink object. At least it achieves better encapsulation, because then
you don't need to poke the sink's "private-ish" data from outside the
sink object. That makes future changes easier to do.

The NOVOLUME flags can be exported to clients, so they can choose to not
show any volume controls. Legacy clients should get the
PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
sinks that have the NOVOLUME flag.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > In your design the PA_SINK_PASSTHROUGH flag means that the sink can be
> used both for exclusive passthrough streams and for normal streams. Are
> you sure we can keep that promise for all future passthrough sinks too?
> It would be cleaner to have strict separation between passthrough sinks
> and non-passthrough sinks. I admit that your approach makes it much
> easier for the user to switch between passthrough and non-passthrough
> content, but that effect could also be achieved with a separate module
> that changes the card profile whenever a passthrough stream is being
> created.

First this passthrough mode is only valid for S/PDIF and HDMI outputs.
In both cases, the receiver may or may not support encoded content,
and in the SPDIF case you have no way of querying what the receiver
capabilities are. You absolutely do not want to send passthrough
streams without making sure the configuration makes sense.
So somehow user interaction is required to explicitly tell PulseAudio
the receiver supports AC3/DTS passthrough. To be more self-explanatory
we should have a check-box in pavucontrol than a different profile.
I really did not want to switch configurations depending on the type
of content, ALSA/iec958 accepts both.

>> +[Element IEC958]
>> +switch = mute
>
> What if this element doesn't exist? Or is it guaranteed to exist? If it
> doesn't exist, then PA will use software muting, i.e. feeding zeroes to
> the device. I don't think that's good. A stream of zeroes is not a valid
> iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and
> streams. Or is alsa capable of switching between passthrough and PCM
> modes on the fly just by inspecting the data?

The IEC958 switch exists on most ALSA cards, I didn't really look into
cases where this would not be supported.
Sending zeroes is fine I guess, the receiver will understand the
samples are not valid and go to a mute mode as well.
There's currently a limitation that this control is locked, but
Takashi agrees this could be removed and it'll be fixed.

>> @@ -163,6 +163,7 @@ struct pa_alsa_path {
>>      pa_bool_t has_mute:1;
>>      pa_bool_t has_volume:1;
>>      pa_bool_t has_dB:1;
>> +    pa_bool_t is_passthrough:1;
>>
>>      long min_volume, max_volume;
>>      double min_dB, max_dB;
>
> is_passthrough doesn't seem to be set anywhere.

Right. I initially wanted to add a statement in the profile
configuration, but I ended-up matching the path name to instead.
Ideally we should extend Lennart's description rather than match
hard-coded names, but this is beyond my programming abilities.

> Previously I claimed that since the the stream is compressed, we
> inevitably will have to extend the code in pa_bytes_to_usec(), but I
> realized now that as long as we pretend that the stream really is a
> regular stereo stream, all calculations end up correct. Now the only
> problem is that the user is given sort of wrong information, but I don't
> think that's a big problem, so I agree with your approach of leaving the
> sample spec alone and relying only on the sink and sink input flags. The
> code can be improved later, if needed.


> About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> First, "non-audio" is not really correct, because the data is still
> audio, but the main issue is the "iec958" part. There can potentially be
> many formats that need to be passed through unchanged, so in the future
> there could be need for PA_STREAM_NONAUDIO_FOO and
> PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> the format information - the format should have its own variable. Until
> new formats are introduced, you can still rely on a single flag, though.
> I propose that you just rename the flags:
>
>  - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
>  - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
>  - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.

I really don't think there are that many formats. The only use cases I
can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
audio. Adding flags on the sinks is no big deal.
The real problem is at the pa_stream level. We don't want to have to
extend the protocol several times. I added a flag but if we have more
than one format we will need more room for subtypes. We should
probably extend the buff_attr attributes for this?
As you have probably read, the addition of this flag breaks the
protocol, and I am really not religious on names/types. I will go with
the majority. Lennart, Colin, your guidance would be more than welcome
here. This is why I posted the patches early to gather feedback.

> I think the most natural place for input compatibility checking is in
> the sink object. At least it achieves better encapsulation, because then
> you don't need to poke the sink's "private-ish" data from outside the
> sink object. That makes future changes easier to do.

I disagree. I think you want a common logic in the core to make sure
that things work the same way no matter what configuration you use.
And its make sure we don't have to modify all existing sinks to
perform the same checks.

> The NOVOLUME flags can be exported to clients, so they can choose to not
> show any volume controls. Legacy clients should get the
> PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> sinks that have the NOVOLUME flag.

Yes the volume needs more work. I don't really understand all this
code through, so for now I disabled the set-volume() routines without
notifying the client. You end-up in the situation where pavucontrol
can change the volume but nothing happens, this is not user-friendly.
Is this NOVOLUME flag an existing one, or something that would need to be added?
Thanks for all your comments
Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote:
> First this passthrough mode is only valid for S/PDIF and HDMI outputs.
> In both cases, the receiver may or may not support encoded content,
> and in the SPDIF case you have no way of querying what the receiver
> capabilities are. You absolutely do not want to send passthrough
> streams without making sure the configuration makes sense.
> So somehow user interaction is required to explicitly tell PulseAudio
> the receiver supports AC3/DTS passthrough. To be more self-explanatory
> we should have a check-box in pavucontrol than a different profile.
> I really did not want to switch configurations depending on the type
> of content, ALSA/iec958 accepts both.

I agree that it's not really a good solution to require the user to
change the card profile manually to enable passthrough via spdif. But as
I said, a separate module could take care switching between the profiles
as needed.

Having thought this for a while, the only thing that really irritates me
in your design is that the semantics of the PA_SINK_PASSTHROUGH become
messy: the flag says that "in addition to normal PCM streams, this sink
supports also passthrough streams, except at times when there already
exist PCM streams, and btw, while a passthrough stream is playing, PCM
streams cease to be supported". I guess that's not a very practical
problem, though.

Ah, but now a better argument popped into my mind. If a sink can enter
the passthrough mode on the fly, then that has a consequence that
affects any application that is interested in sink volumes: whether a
sink has adjustable volume can change any time. That's not very nice.

> > Previously I claimed that since the the stream is compressed, we
> > inevitably will have to extend the code in pa_bytes_to_usec(), but I
> > realized now that as long as we pretend that the stream really is a
> > regular stereo stream, all calculations end up correct. Now the only
> > problem is that the user is given sort of wrong information, but I don't
> > think that's a big problem, so I agree with your approach of leaving the
> > sample spec alone and relying only on the sink and sink input flags. The
> > code can be improved later, if needed.
>
>
> > About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958.
> > First, "non-audio" is not really correct, because the data is still
> > audio, but the main issue is the "iec958" part. There can potentially be
> > many formats that need to be passed through unchanged, so in the future
> > there could be need for PA_STREAM_NONAUDIO_FOO and
> > PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put
> > the format information - the format should have its own variable. Until
> > new formats are introduced, you can still rely on a single flag, though.
> > I propose that you just rename the flags:
> >
> > - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH,
> > - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and
> > - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH.
>
> I really don't think there are that many formats. The only use cases I
> can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power
> audio. Adding flags on the sinks is no big deal.

Even if we have only two formats, iec958 and mp3, I don't see why the
sink flags would the proper place to specify the format. I believe most
of the passthrough related code is only interested in the fact that the
stream data shall not be touched. If there are multiple flags for all
the different passthrough formats, then all that code will have to check
for two flags instead of one.

> The real problem is at the pa_stream level. We don't want to have to
> extend the protocol several times. I added a flag but if we have more
> than one format we will need more room for subtypes. We should
> probably extend the buff_attr attributes for this?

I haven't though about this much, but I have a feeling that more complex
formats (like mp3) are going to need more metadata than currently
available (stuff like bitrate, CBR vs VBR etc.), and if support for
other codecs is going to be needed in the future, the set of metadata
items might vary between codecs. I wouldn't care about all that complex
stuff before it's implemented - in other words, I don't see it as a big
problem if the protocol will have to be extended multiple times for
different codecs. (Of course it would be nice to avoid that, but I
wouldn't trust at least myself to get it right at first try without
actually implementing the mp3 passthrough functionality at the same
time.)

> > I think the most natural place for input compatibility checking is in
> > the sink object. At least it achieves better encapsulation, because then
> > you don't need to poke the sink's "private-ish" data from outside the
> > sink object. That makes future changes easier to do.
>
> I disagree. I think you want a common logic in the core to make sure
> that things work the same way no matter what configuration you use.
> And its make sure we don't have to modify all existing sinks to
> perform the same checks.

There would of course be a standard implementation for sinks that don't
do any "strange" stuff. I thought individual sink implementations could
choose to amend the standard logic, but actually I'm not sure how it
could be done without duplicating code.

Giving it a second thought, the "can this sink input be connected to
this sink" question can be thought equally well as a method of sinks or
sink inputs, or even as a plain old independent function. So, doing it
like you do it in your patch is fine by me (just don't use "iec958"
where the logic isn't really bound to the exact format).

> > The NOVOLUME flags can be exported to clients, so they can choose to not
> > show any volume controls. Legacy clients should get the
> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> > sinks that have the NOVOLUME flag.
>
> Yes the volume needs more work. I don't really understand all this
> code through, so for now I disabled the set-volume() routines without
> notifying the client. You end-up in the situation where pavucontrol
> can change the volume but nothing happens, this is not user-friendly.
> Is this NOVOLUME flag an existing one, or something that would need to be added?

It needs to be added.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I agree that it's not really a good solution to require the user to
> change the card profile manually to enable passthrough via spdif. But as
> I said, a separate module could take care switching between the profiles
> as needed.

I don't understand your proposal. What do you mean by separate
'module' and how would this work with the current mixer profiles?

> Having thought this for a while, the only thing that really irritates me
> in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> messy: the flag says that "in addition to normal PCM streams, this sink
> supports also passthrough streams, except at times when there already
> exist PCM streams, and btw, while a passthrough stream is playing, PCM
> streams cease to be supported". I guess that's not a very practical
> problem, though.

It's not really my design, it's just how SPDIF/HDMI work...

> Ah, but now a better argument popped into my mind. If a sink can enter
> the passthrough mode on the fly, then that has a consequence that
> affects any application that is interested in sink volumes: whether a
> sink has adjustable volume can change any time. That's not very nice.

Duh? If we fixed the volume stuff so that that the volume control app
disables its sliders when passthrough AC3 is enabled, what would be
the issue. This is how VLC works, when you stream AC3 data the volume
control is no longer enabled.

> Even if we have only two formats, iec958 and mp3, I don't see why the
> sink flags would the proper place to specify the format. I believe most
> of the passthrough related code is only interested in the fact that the
> stream data shall not be touched. If there are multiple flags for all
> the different passthrough formats, then all that code will have to check
> for two flags instead of one.

I guess we could have a two-step process, where you first detect if
the sink and sink-input have support for PASSTHROUGH, and then in a
second step you verify that the 'subtype' (iec958 or mp3) is
compatible. The logic for rejecting connections is the same... You
only need one last step to make sure types are compatible.

> There would of course be a standard implementation for sinks that don't
> do any "strange" stuff. I thought individual sink implementations could
> choose to amend the standard logic, but actually I'm not sure how it
> could be done without duplicating code.
>
> Giving it a second thought, the "can this sink input be connected to
> this sink" question can be thought equally well as a method of sinks or
> sink inputs, or even as a plain old independent function. So, doing it
> like you do it in your patch is fine by me (just don't use "iec958"
> where the logic isn't really bound to the exact format).

As I said above, we can have a first pass implemented in the core that
checks things are fine, then a second pass implemented by sinks who
support passthrough mode to check fine-grained compatibility.

>> > The NOVOLUME flags can be exported to clients, so they can choose to not
>> > show any volume controls. Legacy clients should get the
>> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
>> > sinks that have the NOVOLUME flag.
>>
>> Yes the volume needs more work. I don't really understand all this
>> code through, so for now I disabled the set-volume() routines without
>> notifying the client. You end-up in the situation where pavucontrol
>> can change the volume but nothing happens, this is not user-friendly.
>> Is this NOVOLUME flag an existing one, or something that would need to be added?
>
> It needs to be added.

There's already a detection in the mixer code that the hw_volume is
available or not. Maybe we can use this as well.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or
is someone actively looking at developing it?
2. I think that encoding needs to be considered as part of the design ie. the
possibility of AC3 or MP3 encoding before output to SPDIF.

Perhaps you're already past this point, but there is an Alsa utility iecset
which returns (and can set) whether raw data or PCM is being passed to SPDIF. So
presumably the Pulseaudio passthrough for Alsa just needs to call the same
function that utility does.

Can someone point me to any design and API docs for Pulseaudio as I'm interested
in learning where and how it connects to Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > 1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point
> only or is someone actively looking at developing it?

AC3 passthrough works (see patches at start of thread). That said
there are still some opens and feedback is still welcome. I guess this
will be part of Meego at some point, but since there''s nothing hw
specific the discussion takes place in the open.

> 2. I think that encoding needs to be considered as part of the design ie.
> the possibility of AC3 or MP3 encoding before output to SPDIF.

AC3 encoding can be done by selecting the relevant profile
(ac3-iec958). The encoding takes place in alsa-lib a52 plugin. I
initially removed these profiles but took some flak for it, apparently
some people encode their multichannel streams prior to SPDIF
transmission.
I am afraid MP3 encoding in PulseAudio doesn't make sense, not
supported either by SPDIF or HDMI. And for BT use cases, you might as
well encode in SBC if you have PCM in the first place.

> Perhaps you're already past this point, but there is an Alsa utility iecset
> which returns (and can set) whether raw data or PCM is being passed to
> SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call
> the same function that utility does.

iecset sets the AES0-3 bytes, but does not handle actual data
formatting which is done by the gstreamer ac3iec958 element and by the
alsa-lib iec958 plugin. For now I don't even bother to set these bits,
they are so unreliable that receivers usually ignore them.

> Can someone point me to any design and API docs for Pulseaudio as I'm
> interested in learning where and how it connects to Alsa?

No real docs. See the code in src/modules/alsa. Only took me a year to
figure things out :-(
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Fri, 2010-07-09 at 10:51 -0500, pl bossart wrote:
> > I agree that it's not really a good solution to require the user to
> > change the card profile manually to enable passthrough via spdif. But as
> > I said, a separate module could take care switching between the profiles
> > as needed.
>
> I don't understand your proposal. What do you mean by separate
> 'module' and how would this work with the current mixer profiles?

PA_CORE_HOOK_SINK_INPUT_NEW is fired at the beginning of
pa_sink_input_new(). A module can connect to that hook and detect that
"ah, data->flags contains PA_SINK_INPUT_PASSTHROUGH, and data->sink is
NULL, I'll make sure that the passthrough sink is available".

Configuring (automatically) such module would need some extensions to
the card profile code so that this new module could figure out what
needs to be done in order to "make sure that the passthrough sink is
available". My feeling is/was that it's probably doable without too much
difficulty, and that's about as far as I thought about it.

Now, what if data->sink is not NULL? That means that when the client
created the stream, the correct profile was already activated. Or,
alternatively, data->sink points to some "ghost" of a currently
non-existing sink that can, however, be "made real" automatically
somehow. This latter scenario refers to functionality that doesn't
currently exist. Implementing such functionality would require big
changes to a lot of stuff.

I'm starting to like your approach more and more.

> > Having thought this for a while, the only thing that really irritates me
> > in your design is that the semantics of the PA_SINK_PASSTHROUGH become
> > messy: the flag says that "in addition to normal PCM streams, this sink
> > supports also passthrough streams, except at times when there already
> > exist PCM streams, and btw, while a passthrough stream is playing, PCM
> > streams cease to be supported". I guess that's not a very practical
> > problem, though.
>
> It's not really my design, it's just how SPDIF/HDMI work...

Well, when defining the semantics of PA_SINK_PASSTHROUGH you're free to
choose between "combined PCM and passthrough" or "passthrough only".
Either can be made to work with spdif/hdmi. And I think it's not really
specific to spdif/hdmi - both semantics can be used with any passthrough
sink. For example, using your semantics, an A2DP sink can switch between
real-time SBC encoding and passthrough MP3 on the fly similarly how an
spdif sink can change between PCM and passthrough operation. The only
case where the "combined" semantics wouldn't work is when the sink just
plain can't work in any other mode than passthrough. I think it's quite
improbable that we'll ever see such sink.

> > Ah, but now a better argument popped into my mind. If a sink can enter
> > the passthrough mode on the fly, then that has a consequence that
> > affects any application that is interested in sink volumes: whether a
> > sink has adjustable volume can change any time. That's not very nice.
>
> Duh? If we fixed the volume stuff so that that the volume control app
> disables its sliders when passthrough AC3 is enabled, what would be
> the issue. This is how VLC works, when you stream AC3 data the volume
> control is no longer enabled.

What I had in mind was that if changing between PCM and passthrough
modes would require changing profiles, then clients wouldn't need to be
prepared to disable and enable volume control for a sink on the fly.
They would only need to check whether a sink has volume when they
initially create the widget for the sink.

If volume can be disabled on the fly, that pushes more complexity to the
clients, which is not good. But actually I think we'll have to do this,
since the profile-switching module seems impractical.

It seems like all my ideas were crap :)

> > Even if we have only two formats, iec958 and mp3, I don't see why the
> > sink flags would the proper place to specify the format. I believe most
> > of the passthrough related code is only interested in the fact that the
> > stream data shall not be touched. If there are multiple flags for all
> > the different passthrough formats, then all that code will have to check
> > for two flags instead of one.
>
> I guess we could have a two-step process, where you first detect if
> the sink and sink-input have support for PASSTHROUGH, and then in a
> second step you verify that the 'subtype' (iec958 or mp3) is
> compatible. The logic for rejecting connections is the same... You
> only need one last step to make sure types are compatible.
>
> > There would of course be a standard implementation for sinks that don't
> > do any "strange" stuff. I thought individual sink implementations could
> > choose to amend the standard logic, but actually I'm not sure how it
> > could be done without duplicating code.
> >
> > Giving it a second thought, the "can this sink input be connected to
> > this sink" question can be thought equally well as a method of sinks or
> > sink inputs, or even as a plain old independent function. So, doing it
> > like you do it in your patch is fine by me (just don't use "iec958"
> > where the logic isn't really bound to the exact format).
>
> As I said above, we can have a first pass implemented in the core that
> checks things are fine, then a second pass implemented by sinks who
> support passthrough mode to check fine-grained compatibility.

I think I'd just put a new variable in pa_sink and pa_sink_input (or
maybe pa_sample_spec?) that would store the codec information, and do
all checking in the core in one place.

> >> > The NOVOLUME flags can be exported to clients, so they can choose to not
> >> > show any volume controls. Legacy clients should get the
> >> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or
> >> > sinks that have the NOVOLUME flag.
> >>
> >> Yes the volume needs more work. I don't really understand all this
> >> code through, so for now I disabled the set-volume() routines without
> >> notifying the client. You end-up in the situation where pavucontrol
> >> can change the volume but nothing happens, this is not user-friendly.
> >> Is this NOVOLUME flag an existing one, or something that would need to be added?
> >
> > It needs to be added.
>
> There's already a detection in the mixer code that the hw_volume is
> available or not. Maybe we can use this as well.

No, I don't think so. HW volume is a different thing. If a sink doesn't
have HW volume, then it will have SW volume. What we want to tell the
clients is that "this sink or this stream doesn't have volume at all". I
think a new flag for that is a fine solution.

I'm not sure if everyone agrees that the flags should change on the fly,
though, which will happen if a sink can disable volume whenever it
wants. An alternative is to put a new boolean variable to the
pa_sink_info struct. I don't care which solution is chosen.

At server side the situation is the same - shall we add a NOVOLUME flag
to sinks and make it possible to change the flags on the fly, or shall
we add a new "has_volume" boolean variable to pa_sink.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Great news that AC3 passthrough is working. Well done!

Are there any issues with AC3 encoding as I am using the A52 plugin from
Pulseaudio (without your patch) and required the following "hacks":
a. A rate converter in asoundrc:
# Rate Converter to 48kHz, needed for Pulseaudio it seems
pcm.Filter_
RateConvert {
type rate slave {
pcm "Filter_A52Encode" rate 48000
}
}
b. A timeout=0 in default.pa

load-module module-suspend-on-idle timeout=0 # timeout=0 required

Even with these "hacks", I found that sometimes I see:
I: module.c: Unloading "module-alsa-sink" (index: #4).
D: module-always-sink.c: Autoloading null-sink as no other sinks detected.
After I see that, the sink disappears and cannot be selected any more in sound
properties.

1. Does the ac3-iec958 profile resolve any of these issues?
2. Jack has ac3jack. What would be the pros and cons of doing the AC3 encoding
in Pulseaudio instead of in Alsa?

Cheers,
Mike




________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Sat, 2010-07-10 at 08:05 +0000, Michael Rans wrote:
> Even with these "hacks", I found that sometimes I see:
>
> I: module.c: Unloading "module-alsa-sink" (index: #4).
> D: module-always-sink.c: Autoloading null-sink as no other sinks
> detected.
>
>
> After I see that, the sink disappears and cannot be selected any more
> in sound properties.
>
> 1. Does the ac3-iec958 profile resolve any of these issues?

What's "the ac3-iec958 profile"? The iec958-ac3-surround-* mappings that
currently exist in pulseaudio use the a52 alsa plugin, which may or may
not work with Colin's patch[1]. (It didn't work for Colin.)

> 2. Jack has ac3jack. What would be the pros and cons of doing the AC3
> encoding in Pulseaudio instead of in Alsa?

I think it would make sense to do AC3 encoding in Pulseaudio, although
in theory I don't see what difference it would make. Maybe it's somehow
benefical to handle all the buffering inside Pulseaudio. If there are
timing related bugs in the a52 plugin, as Colin seems to think there
are, then it's also a matter of who volunteers first: a person who knows
how to fix the a52 plugin, or a person who knows how to hack AC3
encoding support into Pulseaudio.

[1] https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-June/007311.html

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Thanks for your reply both to my message and the bug I posted.

I tried Colin's patch, but it didn't work for me.

I tried the following evil hack in alsa-sink.c:
out_frames = snd_pcm_rewind(u->pcm_handle, (snd_pcm_uframes_t)
in_frames);
if (out_frames < 0) {
out_frames = -out_frames;
}
/* if ((out_frames = snd_pcm_rewind(u->pcm_handle, (snd_pcm_uframes_t)
in_frames)) < 0) {
pa_log("snd_pcm_rewind() failed: %s", pa_alsa_strerror((int)
out_frames));
if (try_recover(u, "process_rewind", out_frames) < 0)
return -1;
out_frames = 0;
}*/

The sound played but very very fast in Oolite, so I would say it almost worked.

I can't find any definition of snd_pcm_rewind() in the alsa-plugins source code.
Does this function call through to a function in the plugins?

I understand that there a function snd_pcm_hw_params_can_rewind which I would
guess should return false for AC3 encoding - is this called by Pulseaudio?

Cheers,
Mike





________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

Further to my previous message, I tried:
// pa_sink_set_max_rewind(u->sink, u->hwbuf_size);
pa_sink_set_max_rewind(u->sink, 0);

That seemed to fix it, although I fear it will break any other Alsa sinks. Is
there a better way to implement this?

Interestingly, I then no longer need tiemout=0 here:
load-module module-suspend-on-idle

But I still need to go via the rate converter to the a52 encoder in asoundrc.

Cheers,
Mike





________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > But I still need to go via the rate converter to the a52 encoder in
> asoundrc.

Have you set the default sink frequency to 48kHz in
/usr/etc/pulse/daemon.conf? This should handle resampling in
PulseAudio.
Still not clear why rewind doesn't work.
- Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. My default.pa line has rate set at 48000 which I guess would take precedence:
load-module module-alsa-sink device=Filter_RateConvert rate=48000
sink_properties=device.description=SPDIF sink_name=SPDIF)

But just in case, I tried changing default-sample-rate = 48000 in daemon.conf.

The error I got was:

D: alsa-sink.c: snd_pcm_mmap_commit: Resource temporarily unavailable
E: alsa-sink.c: Assertion 'err != -11' failed at modules/alsa/alsa-sink.c:395,
function try_recover(). Aborting.

BTW, I got the setup using a rate converter from here:
http://www.johannes-bauer.com/linux/dolby/?menuid=3 where this chap says "# Rate
Converter to 48kHz, needed for some applications" in his advanced set up. He
didn't mention Pulseaudio, but it seems to do the trick.

Regarding AC3 encoding in Pulseaudio - it would be better because at the moment
switching between stereo and A52 is not possible (ie. I cannot have both these
lines in default.pa:
load-module module-alsa-sink device=Filter_RateConvert rate=48000
sink_properties=device.description=AC3 sink_name=AC3
load-module module-alsa-sink device=ALC889A_Digital
sink_properties=device.description=SPDIF sink_name=SPDIF

Presumably the SPDIF out is locked by one of them, then the other fails. With
ac3 encoding in Pulseaudio, this would be switchable without editing any files.

Cheers,
Mike






________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Sat, 2010-07-10 at 15:40 +0000, Michael Rans wrote:
> Regarding AC3 encoding in Pulseaudio - it would be better because at
> the moment switching between stereo and A52 is not possible (ie. I
> cannot have both these lines in default.pa:
> load-module module-alsa-sink device=Filter_RateConvert rate=48000
> sink_properties=device.description=AC3 sink_name=AC3
> load-module module-alsa-sink device=ALC889A_Digital
> sink_properties=device.description=SPDIF sink_name=SPDIF
>
> Presumably the SPDIF out is locked by one of them, then the other
> fails. With ac3 encoding in Pulseaudio, this would be switchable
> without editing any files.

Switching between stereo and a52 does not require doing the encoding in
pulseaudio. Pulseaudio already provides both stereo and a52 spdif
profiles for alsa cards with spdif output. The a52 profile uses the alsa
plugin to do the encoding. The only problem is, as you know, that the
a52 alsa plugin doesn't seem to work with pulseaudio (at least without
the rate converter workaround). Fixing the plugin (or pulseaudio, if the
cause actually is in pulseaudio) instead of implementing ac3 encoding in
pulseaudio would be a perfectly fine solution.

--
Tanu Kaskinen

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.