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

List:       linux1394-devel
Subject:    Re: [Jackit-devel] alsa pcm_jack plugin
From:       Bob Ham <rah () bash ! sh>
Date:       2003-02-28 12:15:30
[Download RAW message or body]

On Thu, 2003-02-27 at 23:33, Dan Maas wrote:

> 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.

Don't know if I like that, but as long as it works it doesn't matter. 
Not much can be done about it either, so oh well.


> > 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). 

I would much rather have the AMDTP just do the appropriate things with
individual packets rather than putting them on the wire itself.  Ie, in
the protocol stack, have the AMDTP stuff sit *next* to your audio-1394
program rather than between it and the rawiso driver.  I don't know
about the standard at all, so I don't know if it's necessary to do
AMDTP-specific stuff (apart from with the packet format) when getting
data on the wire.


> 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.

Oh man.  That's perfect :)  That's exactly the way we need it to work :)


> 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.

1ms?  Yes, that should be ok :)

Bob

-- 
Bob Ham <rah@bash.sh>



-------------------------------------------------------
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]