[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux1394-devel
Subject:    Re: [Jackit-devel] alsa pcm_jack plugin
From:       Dan Maas <dmaas () maasdigital ! com>
Date:       2003-02-27 23:33:32
[Download RAW message or body]

* Bob Ham (rah@bash.sh) wrote:
> > 1) A machine with a sound card and 1394. In this case I suggest the sound
> > card is the Master clock and 1394 runs unsynchronized.
> 
> I really *really* want to syncronise these clocks.  Is it possible to
> slave an OHCI controller's clock to one not on the bus (and thus force
> the bus to slave to it aswell)?

You can't mess with the 1394 bus clock. However, it doesn't
matter. There does not need to be a fixed relationship between audio
packets and 1394 bus cycles. The 1394 transport protocol (IEC 61883)
allows data to be streamed at any rate. You must send a 1394 packet
each bus cycle, but the packet can contain any amount of audio data
(or even no data at all). All multimedia devices that operate over
1394 employ a rate-control algorithm to packetize their data streams
to the correct average transmission rate.

> Ditto; the 1394 dma engine acts as the alsa interrupt source, which
> eventually initiates the jack graph's processing.

That sounds good. AMDTP will be implemented as a user-space library
that talks with our "rawiso" driver (isochronous transmission and
reception). (currently AMDTP is a kernel module, but that is a
pre-rawiso vestige; it will move into user-space son). 

rawiso uses a fixed-size DMA buffer, which is directly accessible to
the application via mmap(). rawiso uses a "pull"-style API - when the
transmission or reception buffer space reaches a user-specified
threshold, you get a callback to queue outgoing packets or process
incoming packets. I believe this is almost the same as what a sound
card does with its DMA buffer.

rawiso works very efficiently by queueing a batch of many packets with
only one interrupt / trip into the kernel. Now, I know you audio guys
want the lowest possible latency, so you'll probably want to specify a
batch size of one packet. This means the latency of the 1394 stack
will be on the order of a few (<10) bus cycles, probably less than 1ms.

Regards,
Dan



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
mailing list linux1394-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-devel
[prev in list] [next in list] [prev in thread] [next in thread]