[RFC] Passthrough support

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

 



On Tue, 2011-02-22 at 10:03 -0600, pl bossart wrote:
> Hi Arun,
> 
> >> > I've updated this page with the changes discussed so far (and translated
> >> > them into the actual API changes that we need). Please take a look and
> >> > let me know if this looks acceptable.
> 
> Couple of comments:
> - There is a miss on the pa_format_info. the sampling frequency is
> required.  The IEC format can be used at various sampling frequencies.
> Passing just IEC isn't enough to configure the link with the receiver.
> The number of channels could be 2 by default, but we may need to
> change this as well for formats like TrueHD or DTS Master.

I figured it'd be best to leave everything but the format in the
proplist and then let the sink pick out the properties it needs/expects.
This allows us to keep the structure generic and lets sinks specify
what/how much information they need to be able to decide whether a
format is supported or not.

> - in case no IEC formats are supported by the sink, what is the
> returned value? If this is NULL, meaning there is no support, how do
> we fall back to plain PCM?

I assume that the every sink that supports PCM will have one format with
PA_ENCODING_PCM in its list of supported formats. With the extended API,
I'd like to treat PCM and compressed formats as being equal as much as
possible.

> - in case the routing changes, for example if you plug HDMI or BT, how
> do we change the connection?

The plan is to have clients disconnect and recreate the stream. We could
eventually look at a convenience API to do this.

-- Arun




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

  Powered by Linux