From: Johannes Berg <johannes@sipsolutions.net>
To: Takashi Iwai <tiwai@suse.de>
Cc: Lee Revell <rlrevell@joe-job.com>,
ALSA devel <alsa-devel@lists.sourceforge.net>
Subject: Re: ac3 in/out
Date: Wed, 22 Mar 2006 11:54:08 +0100 [thread overview]
Message-ID: <1143024848.11724.64.camel@localhost> (raw)
In-Reply-To: <s5hveu6yd2u.wl%tiwai@suse.de>
[-- 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 --]
next prev parent reply other threads:[~2006-03-22 10:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-21 10:27 ac3 in/out Johannes Berg
2006-03-21 18:17 ` Lee Revell
2006-03-21 18:37 ` Takashi Iwai
2006-03-22 9:41 ` Johannes Berg
2006-03-22 10:43 ` Takashi Iwai
2006-03-22 10:54 ` Johannes Berg [this message]
2006-03-22 11:09 ` Takashi Iwai
2006-03-22 11:12 ` Johannes Berg
2006-03-22 21:39 ` Benjamin Herrenschmidt
2006-03-23 17:06 ` Johannes Berg
2006-03-22 0:20 ` James Courtier-Dutton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1143024848.11724.64.camel@localhost \
--to=johannes@sipsolutions.net \
--cc=alsa-devel@lists.sourceforge.net \
--cc=rlrevell@joe-job.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox