Thread (6 messages) 6 messages, 2 authors, 2006-03-24

Re: new sound driver

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2006-03-23 17:13:47

On Thu, 2006-03-23 at 08:50 +1100, Benjamin Herrenschmidt wrote:
that would make soundbus totally pmac specific, in which case you should
call it aoa-bus or something like that.
Yeah, well, I just did it differently now with the dbdma stuff done by
the i2sbus objects.
Regarding your previous question well... I think the soundbus can create
the pcm streams. Alsa has 2 levels: PCM objects and PCM substreams. We
need the former. Substreams are used when the harware has several
streams that are hw mixed to the same mixers which isn't the case with
apple layout. When we have multiple i2s busses, they are really
independant with separate codecs, frame rates & formats etc.. thus
separate PCM objects.

I think the sound bus should create the PCMs. Now I don't remember from
Alsa API but do we need to know the available rates in advance ? In that
case, we may want to have the bitmask provided by the fabric (from the
layout array for example).
Right. I was still confused on the notion of PCM streams vs. objects.
Got that sorted out, and yes, it is creating pcm objects.
I'm also not sure how Alsa handle changes there. For example, if you
plug a digital input, the entire bus where this input is has to be
clocked from that, thus limiting dynamically what rates/formats are
available. I'm not sure Alsa API can cope with that yet.
Well, if we're unlucky the Alsa API must just return -EINVAL to users
trying to use other bitrates, if we're lucky then it copes better ;)
quoted
Actually, this isn't quite possible. On the newer machines where you
have two codecs on the same i2s bus, we need to have the layout fabric
create the one pcm stream and have it ask the codecs what it should
advertise. Then it needs to advertise the lowest common denominator of
the multiple codecs... (Or can alsa handle pcms that change their
supported rates/formats?) Then it refers to the soundbus functions for
actual data transmission.
The problem is that codec objects have to be created asynchronously
since they use asynchronous i2c discovery. Unless you instanciate them
all but simply mark them "offline" and then mark them "online" later
when the hardware actually shows up. That is fine except for .. topaz
where you need to access the hw to know the chip type, thus you can't
really know everything you need early enough (or maybe you can ...)
What I'm currently thinking of is creating one PCM per codec, and then
if you can't use them at the same time just forbid access to it.
 
Just sleep on it for now :) We definitely need a "core" module that
handles all of the gpio mess. ..
Yeah. Haven't even opened that can of worms yet...

johannes

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help