Re: Synchronization problem in 10.2: physical memory
Re: Synchronization problem in 10.2: physical memory
- Subject: Re: Synchronization problem in 10.2: physical memory
- From: Michel <email@hidden>
- Date: Fri, 4 Oct 2002 23:37:28 +0100
On Friday 04 October 2002 18:42, Mark Cookson wrote:
>
Using and IOMemoryDescriptor, you
>
can even make the end of the ring buffer look like it's attached to the
>
front of the ring buffer. This allows you to seamlessly wrap around
>
the buffer without the code that's preparing the DMA transfer
>
descriptors even noticing, a very cool feature that I take advantage of
>
in the AppleUSBAudio driver.
Your driver handles 2 channels of 16 bits at 44.1kHz.
So, using the typical IOMemoryDescriptor, you will have 'ranges' of physical
memory that are ... ONE page long in most case -I just tried-
That mean that your driver will get an interrupt every 24.915 ms to realign
the controler.
My device however has 12x32 bits channels. That mean that I will have to
switch buffers every 1.778 ms to do what you do. Thats far from what I'd call
'cool.
Beside, the DMA controler uses only 28 bits of addresses, so the more segment
of physical memory I have, the higher the risk or having one fragment in the
midddle that I just can't use because it's too high.
So, you want me to annoy a few kernel programmers, or get the machines to
it's knees to go around an operating system issue? I mean, that device works
perfectly on linux & windows. In fact, in the windows driver, they use a
rather neat Malloc equivalent; you pass it a mask and it will arrange to get
you a segment that fits it. Neat!
To approximate your 24 ms rate, I need fragments of 1024 frames too, however,
thats 49152 bytes here. Thats what I use at the moment.
So, it all falls back to why the mixing doesn't work with small buffer sizes.
As we discovered, using 512 frames just makes the IOAudioEngine fail
completely with the clipIfPossible() syndrom.
After reading your description on how things work, I conclude that what I am
doing with my ghost buffer can't make the mixing fail. I need a fake buffer
because in that case the stream is configured with 8 interleaved channels,
while the DMA has 12. So I need to convert 8, skip 4, convert 8, skip 4 etc
etc. The IOAudioStream lacks a 'stride' parameter here.
Anyway, in clipOutputSample, I ignore the destination buffer but that
SHOULDN'T make a difference UNLESS the mixer was poking back values from that
buffer to reinject into the mix when another client intervene.
My assumption is that all the mix appends in the private mix buffer, and that
the IOAudioEngine will never touch the content of the buffer I passed unless
I do so myself in clipOutputSample.
Things are exactly reversed in convertInputSamples, I also ignore the
'source' buffer that is sized for 8 channels, and I go fish in my DMA, at the
same equivalent offset, then fills the destBuffer.
So, we fall back to the case where I suspect that 1024 samples is not enough
for the mixer to function properly. If the system I implemented was not
working, it would not work at all.
If 1 client works but 2 clients makes the system fail, considering that the
IOAudioEngine -as far as the driver writer is concerned- has no knowledge on
how many client there is, I can assume that the problem lies elsewhere.
What I SUSPECT happends is that when the second client arrives, the
calculation as to where it's samples should go fails because their time stamp
is too old, thus it's destination wraps back the buffer into the 'future' of
it. and thus gets overriten by the mixer when it arrives at that point for
the client 1.
--
Linux yawn 2.4.19-ac4 #49 Tue Aug 6 10:13:51 BST 2002 i686
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.