On 1/08/2015 2:52 PM, Toby Gifford wrote:
> Thanks Ross, that's very cool! And topical. That'll larn me for not
> reading recent ACMC proceedings :)
>
> My al-foil & chewing-gum answer to avoiding 'unbounded priority
> inversion' in the audio-thread is to only ever call pthread_trylock in
> that thread.The file-I/O-thread on the other hand calls pthread_lock.
It sounds great if you can make it work. I never looked deeply into
try-locks. I would love to see a streaming scheme using try-locks that
is proven 100% reliable. Although your mention of LPC loss concealment
suggests you aren't there yet.
Lock-free isn't a panacea. It has taken more than 10 years for me to get
any confidence in using lock-free algorithms -- and even then the
pitfalls are myriad.
> The critical section in the file-I/O-thread just needs to change the
> value of a pointer, so I assume it would be unusual for this lock to be
> held right when the audio-thread tries it.
I'm aiming for something where the inter-thread communication is more
reliable than "probably won't fail." My end goal is wait-free,
guaranteed O(1) for every sample. The approach in the paper I mentioned
is a first step in that direction. It is worst-case O(N) per buffer-flip
in the length of the buffer queue. The audio->IO queue in the paper is
not wait free.
> And in the (presumably rare)
> cases when it does a simple Linear Predictive Coding extrapolation from
> the last few samples (the trylock is done on a sample by sample basis)
> should be fairly imperceptible?
From my limited experience with LPC packet loss concealment, I'd
suggest that it might be perceptible under some circumstances. I'd also
be worried about the CPU overhead.
The approach that I take is to buffer (prefetch) some amount of data in
the audio thread, so that any I/O jitter is masked. There needs to be
enough buffering to mask the worst-case latency of I/O operations. In
other words, it doesn't really matter if data is delayed a little bit,
the audio thread always has enough prefetched data to work with.
> I guess its possible that the
> file-I/O-thread gets suspended after locking by a higher priority
> thread, and so the audio-thread ends up missing a whole buffer. Maybe
> giving the worker thread real-time priority with a super-short duty
> cycle would help?
I would certainly suggest making the I/O thread run at higher priority
than most other threads, but lower priority than the audio thread.
Both the I/O thread and the audio thread need to be guaranteed some CPU
time in order to avoid drop outs. Buffering between the IO and audio
thread can mask jitter in IO thread scheduling (whether caused by
pre-emption or waiting for IO operations), but it still requires that
the jitter is bounded.
On a single CPU system, assuming audio runs at higher priority than I/O,
it could be possible to starve the IO thread with very high audio CPU
utilisation. I don't have a solution for that. It's less of an issue
with multi-core systems.
> Anyway, i'm probably better off implementing your lock-free approach.
Even if you don't go the lock-free route, I do think that it would be
worth looking at the paper to see how I modeled the problem.
The paper uses message passing via lock-free queues. This is relatively
easy to reason about correctness, which is the main advantage of the
approach. Another key feature is that the algorithms allow for lock-free
memory management of asynchronously consumed buffers, without a garbage
collector. You still need to explicitly close a stream though -- if you
don't, resources leak.
Good luck!
Ross.
> On Thu, Jul 30, 2015 at 9:19 PM, Ross Bencina <
ro...@audiomulch.com
> <mailto:
ro...@audiomulch.com>> wrote:
>
> On 29/07/2015 2:39 PM, Toby Gifford wrote:
>
> For context I have attached my YbotAudioFileReader library
> below. The
> idea of it is to 'stream' an audio file from the disk, and allow for
> seamless random access playback, but without having to load it
> entirely
> into memory.
>
>
> Hi Toby,
>
> Maybe my paper on how to do file streaming without mutexes or
> allocation in the audio thread will help:
>
>
http://www.rossbencina.com/code/interfacing-real-time-audio-and-file-io
>
> It doesn't get around the apparent problem of extempore's lack of
> finalizers, but it might give you some ideas.
>
> Cheers,
>
> Ross.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Extempore" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to
extemporelan...@googlegroups.com
> <mailto:
extemporelang%2Bunsu...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "Extempore" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
extemporelan...@googlegroups.com
> <mailto:
extemporelan...@googlegroups.com>.
--
===================================
AudioMulch 2.2 modular audio software for PC and Mac
http://www.audiomulch.com
---
Everything else:
http://www.rossbencina.com