ac3 in/out

ac3 in/out

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

Hi,

From what I've seen about ac3 in and also out, the support in alsa for
that is more of a hack, and the data that is passed down the pcm
interface actually contains the channel status bits for some drivers...
Working on the new Apple stuff this isn't possible -- only some channel
status bits can be set by the software, some are fixed. And they aren't
interleaved in the stream, but set externally.

So the question is -- are there any plans to abstract some digital out
API within alsa? Otherwise the userspace will need to handle all kinds
of different devices differently since the data on the stream is
essentially the same as the data the chipset needs.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: ac3 in/out

[Lee Revell]

On Tue, 2006-03-21 at 11:27 +0100, Johannes Berg wrote:
> Hi,
> 
> From what I've seen about ac3 in and also out, the support in alsa for
> that is more of a hack, and the data that is passed down the pcm
> interface actually contains the channel status bits for some drivers...
> Working on the new Apple stuff this isn't possible -- only some channel
> status bits can be set by the software, some are fixed. And they aren't
> interleaved in the stream, but set externally.
> 
> So the question is -- are there any plans to abstract some digital out
> API within alsa? Otherwise the userspace will need to handle all kinds
> of different devices differently since the data on the stream is
> essentially the same as the data the chipset needs.

I don't understand - ALSA fully supports AC3 passthrough and digital
audio.

What is the exact problem you are trying to solve?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: ac3 in/out

[Takashi Iwai]

At Tue, 21 Mar 2006 13:17:04 -0500,
Lee Revell wrote:
> 
> On Tue, 2006-03-21 at 11:27 +0100, Johannes Berg wrote:
> > Hi,
> > 
> > From what I've seen about ac3 in and also out, the support in alsa for
> > that is more of a hack, and the data that is passed down the pcm
> > interface actually contains the channel status bits for some drivers...
> > Working on the new Apple stuff this isn't possible -- only some channel
> > status bits can be set by the software, some are fixed. And they aren't
> > interleaved in the stream, but set externally.
> > 
> > So the question is -- are there any plans to abstract some digital out
> > API within alsa? Otherwise the userspace will need to handle all kinds
> > of different devices differently since the data on the stream is
> > essentially the same as the data the chipset needs.

The SPDIF status bits are generic and rather depending on the data
than the device you output.  That is, more or less, the SPDIF I/O is
abstracted.

> I don't understand - ALSA fully supports AC3 passthrough and digital
> audio.
> 
> What is the exact problem you are trying to solve?

Regarding AC3, I'm not against to create a new easy-to-use API
function.  One reason is that AC3 over SPDIF needs conversions of
packets and also requires the sync work, in addition to the SPDIF
status bits mentioned in the above.  Such a job can be certainly
hidden in the system instead of application itself.

If we create a new one, we should better think of other compressed
formats, too...


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: ac3 in/out

[James Courtier-Dutton]

Johannes Berg wrote:
> Hi,
> 
> From what I've seen about ac3 in and also out, the support in alsa for
> that is more of a hack, and the data that is passed down the pcm
> interface actually contains the channel status bits for some drivers...
> Working on the new Apple stuff this isn't possible -- only some channel
> status bits can be set by the software, some are fixed. And they aren't
> interleaved in the stream, but set externally.
> 
> So the question is -- are there any plans to abstract some digital out
> API within alsa? Otherwise the userspace will need to handle all kinds
> of different devices differently since the data on the stream is
> essentially the same as the data the chipset needs.
> 
> johannes

What is the problem?
Application like xine and mplayer don't seem to have any problems with
AC3 out.

James



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: ac3 in/out

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

On Tue, 2006-03-21 at 19:37 +0100, Takashi Iwai wrote:

> The SPDIF status bits are generic and rather depending on the data
> than the device you output.  That is, more or less, the SPDIF I/O is
> abstracted.

Are you talking about alsa or spdif itself?

> Regarding AC3, I'm not against to create a new easy-to-use API
> function.  One reason is that AC3 over SPDIF needs conversions of
> packets and also requires the sync work, in addition to the SPDIF
> status bits mentioned in the above.  Such a job can be certainly
> hidden in the system instead of application itself.

Yes, but apparently some hardware is capable of doing the conversion
(the chip apple uses for example: pcm3052, download data sheet for
pcm3052a if you're interested, it's the same chip)

On the other hand, some other chips seem to rely on software to
multiplex the channel status bits into the bitstream which is currently
done by userspace as far as I can tell.

> If we create a new one, we should better think of other compressed
> formats, too...

They're essentially the same to the spdif output though -- just a
non-pcm bitstream.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: ac3 in/out

[Takashi Iwai]

At Wed, 22 Mar 2006 10:41:22 +0100,
Johannes Berg wrote:
> 
> On Tue, 2006-03-21 at 19:37 +0100, Takashi Iwai wrote:
> 
> > The SPDIF status bits are generic and rather depending on the data
> > than the device you output.  That is, more or less, the SPDIF I/O is
> > abstracted.
> 
> Are you talking about alsa or spdif itself?

I mean ALSA spdif PCM interface.

> > Regarding AC3, I'm not against to create a new easy-to-use API
> > function.  One reason is that AC3 over SPDIF needs conversions of
> > packets and also requires the sync work, in addition to the SPDIF
> > status bits mentioned in the above.  Such a job can be certainly
> > hidden in the system instead of application itself.
> 
> Yes, but apparently some hardware is capable of doing the conversion
> (the chip apple uses for example: pcm3052, download data sheet for
> pcm3052a if you're interested, it's the same chip)

We don't support these chips yet :)

> On the other hand, some other chips seem to rely on software to
> multiplex the channel status bits into the bitstream which is currently
> done by userspace as far as I can tell.

Yeah, that's the current situation.

> > If we create a new one, we should better think of other compressed
> > formats, too...
> 
> They're essentially the same to the spdif output though -- just a
> non-pcm bitstream.

Yes.

To clarify what I thought in the above:
The conversion itself wouldn't be too difficult.  ALSA-lib has already
many conversion plugins, e.g. iec958 plugin packs to 32bit spdif
frames.

The problem of compressed stream is that the rates of the input stream
and the output audio signal are different especially if the input
stream is VBR.  This style of input stream doesn't match with the
current ALSA style because ALSA PCM assumes the constant rate.
Changing this is more harder work. 


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: ac3 in/out

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

On Wed, 2006-03-22 at 11:43 +0100, Takashi Iwai wrote:

> > Yes, but apparently some hardware is capable of doing the conversion
> > (the chip apple uses for example: pcm3052, download data sheet for
> > pcm3052a if you're interested, it's the same chip)
> 
> We don't support these chips yet :)

Well I know, I'm writing a driver for it, hence my posting here :)

> > On the other hand, some other chips seem to rely on software to
> > multiplex the channel status bits into the bitstream which is currently
> > done by userspace as far as I can tell.
> 
> Yeah, that's the current situation.

Ok that's what I figured. Well, it has to change if I shall be able to
write a driver for the digital output of above chip.

> To clarify what I thought in the above:
> The conversion itself wouldn't be too difficult.  ALSA-lib has already
> many conversion plugins, e.g. iec958 plugin packs to 32bit spdif
> frames.

Ok. But this still means that we have to export the information on what
kind of input we expect. As I said, above chip can't take a stream
that's interleaved with the channel status, yet other chips need that
kind of stream. If we want to have a unified API we need to interleave
the stream with the channel status bits for the cards that need that,
and have userland present the channel bits and the stream in different
controls, where there's even a bitmask present of which channel bits can
be changed...

> The problem of compressed stream is that the rates of the input stream
> and the output audio signal are different especially if the input
> stream is VBR.  This style of input stream doesn't match with the
> current ALSA style because ALSA PCM assumes the constant rate.
> Changing this is more harder work. 

That's another issue, I haven't even started thinking about that.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: ac3 in/out

[Takashi Iwai]

At Wed, 22 Mar 2006 11:54:08 +0100,
Johannes Berg wrote:
> 
> On Wed, 2006-03-22 at 11:43 +0100, Takashi Iwai wrote:
> 
> > > Yes, but apparently some hardware is capable of doing the conversion
> > > (the chip apple uses for example: pcm3052, download data sheet for
> > > pcm3052a if you're interested, it's the same chip)
> > 
> > We don't support these chips yet :)
> 
> Well I know, I'm writing a driver for it, hence my posting here :)
 
Good to know :)

> > > On the other hand, some other chips seem to rely on software to
> > > multiplex the channel status bits into the bitstream which is currently
> > > done by userspace as far as I can tell.
> > 
> > Yeah, that's the current situation.
> 
> Ok that's what I figured. Well, it has to change if I shall be able to
> write a driver for the digital output of above chip.
> 
> > To clarify what I thought in the above:
> > The conversion itself wouldn't be too difficult.  ALSA-lib has already
> > many conversion plugins, e.g. iec958 plugin packs to 32bit spdif
> > frames.
> 
> Ok. But this still means that we have to export the information on what
> kind of input we expect. As I said, above chip can't take a stream
> that's interleaved with the channel status, yet other chips need that
> kind of stream. If we want to have a unified API we need to interleave
> the stream with the channel status bits for the cards that need that,
> and have userland present the channel bits and the stream in different
> controls, where there's even a bitmask present of which channel bits can
> be changed...

Yes, I've understood your demand.
As mentioned, there is no API yet, so proposals are welcome.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: ac3 in/out

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

On Wed, 2006-03-22 at 12:09 +0100, Takashi Iwai wrote:
 
> Good to know :)

If you're interested:
http://ozlabs.org/pipermail/linuxppc-dev/2006-March/021524.html

> Yes, I've understood your demand.
> As mentioned, there is no API yet, so proposals are welcome.

Good :)
But I really do need a better understanding of alsa before I can create
a proposal. Is there any good documentation on how the pcm interface
works? Internally, I mean, not the API. I'm mostly interested in the
order of calls to the operations.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: ac3 in/out

[Benjamin Herrenschmidt]

On Wed, 2006-03-22 at 11:54 +0100, Johannes Berg wrote:

> Ok that's what I figured. Well, it has to change if I shall be able to
> write a driver for the digital output of above chip.

Well, you can be sneaky in the meantime :) If you use small buffers and
large dbdma command lists, you can have the dbdma command list skip the
status data but that mean one output command per sample (or packet),
fairly horribly inefficient if your ratio data/status is not high :)

But then, as I said, ac3 is fairly low throughput so it may be worth
just doing a conversion pass in the driver before the DMA...

> > The problem of compressed stream is that the rates of the input stream
> > and the output audio signal are different especially if the input
> > stream is VBR.  This style of input stream doesn't match with the
> > current ALSA style because ALSA PCM assumes the constant rate.
> > Changing this is more harder work. 
> 
> That's another issue, I haven't even started thinking about that.

It's very similar to the limitations of apple's old sound manager ;)
they never properly fixed it btw ... they just rewrote everything
completely for OS X ...

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: ac3 in/out

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

On Thu, 2006-03-23 at 08:39 +1100, Benjamin Herrenschmidt wrote:

> > Ok that's what I figured. Well, it has to change if I shall be able to
> > write a driver for the digital output of above chip.
> 
> Well, you can be sneaky in the meantime :) If you use small buffers and
> large dbdma command lists, you can have the dbdma command list skip the
> status data but that mean one output command per sample (or packet),
> fairly horribly inefficient if your ratio data/status is not high :)

I don't think so, since the user/channel status bits are interleaved
*bitwise* :)

Though there's another thing I don't yet understand. If you look at the
three datasheets of the topaz chips, you'll notice that one of them is a
receiver, one of them a transmitter, and the third a transceiver! Now I
really wonder wtf apple is doing with them.
But to find out that, I first need to write a topaz module that probes
which one of the chips it is :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]