Re: HALOutputUnit (Pt 2)
Re: HALOutputUnit (Pt 2)
- Subject: Re: HALOutputUnit (Pt 2)
- From: Bob Stuller <email@hidden>
- Date: Tue, 24 Feb 2004 21:22:24 -0500
Doug, Greetings!
At 5:38 PM -0800 2/24/04, Doug Wyatt wrote:
Ah, now that I see what's going on. We don't (currently) allow
sample rate conversion on input. The constraint in the current
design is that the client must pull *all* of the input from the unit
during each I/O cycle, and I guess there was some sense that it was
too tricky to describe how to do this in the presence of an SRC.
That said:
[a] if you do have hardware that runs at 16K, you should be able to
run the AUHAL at 16K too. I'm sure I've successfully recorded from
it at 48K... it should be a matter of making sure you set the
element 1/output scope to match the hardware sample rate, which
should be readable from element 1/input scope.
[b] you could pull all the data out into a ring buffer and do the
downsampling on another thread. The I/O unit uses an AudioConverter
to do rate conversions internally, but you can also use your own
converter externally.
Ooo! This sounds hopeful. I have structured my code to do this:
Negotiate the device's best format (requiring least conversion), get
the HALAU to give that to me, then I use Kurt Revis' most-excellent
Virtual Ring Buffer (translated in C++, if anyone wants this...) to
get the unconverted samples into another thread (paced by some
pthread_cond_timedwait code that Kelly Jacklin contributed to the
list) that owns an AudioConverter that handles the rest of the
converting. Essentially, I had hoped to have the HALAU do the
deinterleaving, shutting down of extra channels, etc. & do the rest
at my leisure.
And, this all works except that I get garbage. The callback gets hit
at a pace that tells me that the HALAU is running at 44.1kHz. When I
ask HALLab what is going on with the device, it says, "Running
Somewhere: NO" So, you can see why I tended to believe Aaron.
Now I am wondering: You say, "... match the hardware sample rate,
which should be readable from element 1/input scope." The mystery is
at what point does the hardware's sample rate get set on element 1's
input scope? I can't do it externally: That end of the input bus is
read-only.
Perhaps it is the order of events that is crucial here. Am I
mumbling the magic words in the wrong order? Should the device's
sample rate already be set before it is attached to the HALAU's
input? I don't think that is going to work since the methodology
outlined above ends up with the device's format set correctly. But I
can try it quickly enough... Nope.
I added a ReadProperty on the input scope's format and do in fact
find it to be set to 44.1kHz. Darn! This is the broken part! The
device is set right, the output of the HALAU is set right... only the
input is wrong.
Peace,
Bob
--
Imagination is more important than knowledge.
- Albert Einstein
_______________________________________________
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.