Subject: Re: [linux-audio-dev] LAAGA - main components
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Thu May 03 2001 - 21:27:53 EEST
Paul Davis wrote:
> the SPARC's cache architecture means that 32 bit writes and reads are
> not atomic on an SMP system. The way the cache lines are structured,
> you can end up suffering a partial-cache miss on a 32 bit value. if
> you look at the linux code for atomic_t on the sparc, you'll see it
> requires explicit locking to make it safe, and an atomic_t on that
> architecture is only a 24bit value (definitely not a pointer!)
Thanks for the pointer to atomic_t in the kernel source. This gives
me what I needed - for everything but the S390, atomic_read() and
atomic_set() map to plain read and write. For SPARC, some shifting
goes on, but this is only to enable atomic_add() and friends. I'm
satisfied now, and feel a little more confident with this approach.
> right, this is true - as long its a (one-writer; read-many) thing,
> then you don't need a lock, but that doesn't address the fact that it
> describes a list that gets manipulated by the engine. the engine may
> modify the list as i described previously. this means that the "copy
> the list, then swap pointers approach won't work.
I'm going to have to spend some time with your source to understand
what you're doing before I can make any more suggestions.
> we just use pthread_mutex_trylock(). if the audio thread (in
> AudioEngine::process(), called from the code that was woken from
> poll(2)) can't get the lock, it just throw its hands in the air and
> says "OK, I have nothing to do", and returns
> :::
> do nothing at all (hence the click - no audio is
> produced or generated for this interrupt, though we do silence the
> relevant part of the audio interface DMA buffer).
Thanks for the detailed explanation of this - I'm much clearer on this
area now. I also took a look at the source of linuxthreads, which is
interesting.
> this is another example where the "no system calls" rule breaks
> down. with the linux pthreads implementation, you can't use any kind
> of mutex without a system call to wake up threads that are blocked on
> the lock.
I think with some work I may be able to find ways to eliminate most if
not all of these locks. I need to get to know your code first,
though.
...
On a slightly different topic, I now know precisely how we can handle
external apps connected to the server as an `external loop' using a
fixed latency. Let's say we're going to connect up to aRts using a
predefined 250ms latency (250ms is just for illustration - I don't
know what would be a realistic figure in this scenario). We allocate
buffers for both input and output with enough room for 250ms of sound.
We initialise the outgoing buffer to zero length, and the incoming
buffer to 250ms of silence (i.e. full). Then we say `go!'.
In each iteration of the main loop of the real-time server, we put one
chunk of data into the outgoing buffer, and take one chunk of data out
of the incoming buffer. Some parallel thread will relay the outgoing
chunk to aRts somehow [*], which will duly process that through its
network and at some later point (according to processor load, etc)
return a processed chunk, which will go into the incoming buffer.
So long as this round trip takes less than 250ms, the incoming buffer
will never be empty, and the real-time thread will always be happy.
This same scheme can be extended to longer latencies if necessary, for
instance if the round-trip is going to have to travel over a network.
I hope this shows how we can mix external medium- or high-latency apps
and plugin low-latency apps without too much difficulty.
Jim
[* or inform aRts that it has some data to pick up from the buffer
directly ]
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim_AT_aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
This archive was generated by hypermail 2b28 : Thu May 24 2001 - 00:26:20 EEST