[RFC] Passthrough support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Please review/comment. Once we have some consensus, I'll send in patches
> to actually get this done.

Thanks Arun,
this is a good start. Couple of comments:
- change raw to PCM, it's less ambiguous.
- I am not sure I understand how/when the query would be used. Seems
to me like a notification with the formats exposed by the sink
currently selected would be more usable. And if a change in routing
happens (new accessory, audio policy, etc), the client is informed and
can reconfigure to PCM if need be.
- I think we need to look at the 'start_move' and 'finish_move' as
well. If a reconfiguration to PCM is needed, we may need to wait until
the client sends PCM again?
- I am not sure the channel map matters for compressed data. The
receiver will adjust anyway to the actual number of speakers, e.g.
downmix if you use a headset.
- you want to add E-AC3 as a basic format. It uses a different IEC syntax
- The receiver may support the same format at different sampling
frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for BT).
We will need to list explicitly which sampling frequencies are
supported for each format.
- Changing the monitor is tricky, we may want to keep it but either
tag the data as IEC as well, or just zero out.
- On deprecating the PA_SINK_INPUT_PASSTHROUGH: yes it can be removed
as long as you have some means to signal that the data isn't your
ordinary PCM. Extending the pa_sample_spec would break the API, I vote
for a proplist here.

I am sure others will have some remarks as well.
-Pierre



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux