Re: coreaudio usb driver
Re: coreaudio usb driver
- Subject: Re: coreaudio usb driver
- From: Jeff Moore <email@hidden>
- Date: Mon, 01 Dec 2008 15:10:43 -0800
On Dec 1, 2008, at 12:10 PM, Eugene Gavrilov wrote:
I'm developing a driver for Mac OS X for USB 2.0 and 1.1 devices
(which are not class-compliant).
I noticed that sometimes IOAudioEngine::clipOutputSamples() function
sends a request with 'numSampleFrames' = 0. Is this correct?
Probably.
Why can this happen?
My guess would be that this is coming about due to the erase head not
thinking it has anything to erase when it runs.
Can this influence driver performance or indicate any problems with
the timestamps?
It probably doesn't cause any performance problems but it could be
indicative of issues with your time stamps or with your implementation
of IOAudioEngine::getCurrentSampleFrame()
I'm also getting resetClipPosition() notification - but I don't know
whether I need to deal with it or not.
This comes about when a new client wants to start at a point in time
that has already been clipped. Generally, the Family will handle
dealing with this for you.
Original "Apple USB Audio Driver" has a set of very complicated
timestamp calculation algorithms with separate anchored time stamp
timers and jitter filters.. Is there a way to implement it in a less-
complex way?
Our USB Audio class driver does what it does in order to provide the
most accurate time stamps to the system that it can using the USB
controller hardware that is present. Presumably because your driver is
running on the same OS and the same controller hardware, not doing
this sort of thing will result in your driver providing less accurate
time stamps. Our history with USB Audio has shown that this can be
very problematic.
My audio driver works quite fine, even with very small buffer sizes
(32, 64 samples), but I'm experiencing problems with certain 3-rd
party software, such as 'Cubase LE': there are occasional clicks and
"click storms", especially right after sampling rate change - and in
some cases the application can not recover automatically - even
after a number of manual resets. (But my driver + Apple aggregated
driver + Cubase work fine, without problems).
I suspect the problem is with synchronous start-up of the two audio
engines (playback and recording), as they are implemented
independent in my driver (similar to Apple USB Audio Driver), but I
don't know where to dig into..
To be honest, this description of the problem makes me think that
there is some serious issues with your driver's time stamps. It also
could be that your safety offset is too small.
Is there a way to check the timestamps calculated by the driver? I
tried "HALLab" application, but it does not show any problems with
the timestamps: they seem to be reported accurately, "Late" field is
always less than 0.1 ms.
Just because they are all reported and the Late field is in the
microsecond range doesn't mean things are running correctly. At any
rate, do you see any IO cycles displayed in red by HALLab? Red cycles
indicate that an error or some other kind of problem happened.
Is there any documentation on HALLab available?
Not really, but it is on my list of things to do.
I would appreciate any help on this topic, thank you in advance!
All the symptoms you've reported make me think that there is either a
problem with the quality of your driver's time stamps or possibly that
the safety offset is too small (which could be an indication that the
time stamps have too much jitter in them).
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden