[haiku-development] Re: Multi Audio Specification

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 13 Dec 2009 20:47:06 +0100

On 2009-12-13 at 17:59:56 [+0100], Jérôme Duval <korli@xxxxxxxxxxxxxxxx> 
wrote:
> 2009/12/13 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> > The article refers to the documents multi_audio.gb and multi_audio.txt as
> > the '"complete" documentation'. Does anyone have these files?
> 
> I don't. They are also not part of
> ftp://ftp.beos.hu/pub/beos/development/samples/drivers/multiaudio_test.zip.

François kindly sent them to me.

> >> Better ask questions here :)
> >
> > I'm primarily interested in the exact semantics of the
> > B_MULTI_BUFFER_EXCHANGE call. Particularly whether indeed all fields of
> > multi_buffer_info structure are output parameters -- the doxygen comment 
> > at
> > the HDA driver's buffer_exchange() function suggests that
> > playback_buffer_cycle isn't, but it still completely ignores it -- and 
> > what
> > the call is supposed to be waiting for -- the end of the currently played
> > buffer or shall it indeed return immediately (with incorrect return
> > values), if B_MULTI_BUFFER_EXCHANGE wasn't called for a previous buffer, 
> > as
> > the HDA driver does.
> 
> B_MULTI_BUFFER_EXCHANGE is supposed to wait for an event (buffer
> played or recorded).

Yeah, well, that's a bit fuzzy. Unfortunately the documentation isn't really 
that detailed either.

> As of now, the media addon has to follow the
> driver buffer cycles, mainly because it is following the hardware DMA
> read/write cycles. So yes, IMO output parameters. From the article:
> "This call is synchronous -- it returns after playback data has been
> transferred (or queued) and capture data (if any) is present in the
> capture buffer."
> Though if you look at the loop_test in multiaudio_test.zip, the
> structure isn't even used (lots of hardcoded values anyway).

> Hope this helps.

Thanks!

CU, Ingo

Other related posts: