Re: [linux-audio-dev] streaming from disk to terminatorX added (via mmap)

Re: [linux-audio-dev] streaming from disk to terminatorX added (via mmap)

[Paul Barton-Davis]

Benno writes:

>Since the kernel loads pages of the file into mem when they are
>needed, it could cause audio-dropouts when working with low audio
>buffer sizes (low latency) since, the playing thread might wait too
>long for the kernel which tries to load the pages into mem.

>One trick to avoid this it to add a low priority thread , which does
>basically read-ahead and read-behind, by accessing to pages before
>and past the actual playing position.  It doesn't matter if this
>thread blocks for a moment, since it doesn't play any audio data.
>The audio thread will always find the needed pages in memory and will
>not drop out.

i know that est@hyperreal.org will have something to say about this :)
well, perhaps not, but he should. oolaboola (sp?) has been evolving
toward some fairly sophisticated memory management to handle this kind
of stuff.

Re: [linux-audio-dev] streaming from disk to terminatorX added (via

[Andy Lo A Foe]

On Sun, 24 Oct 1999, Benno Senoner wrote:

> Suggestions to the author:  (any official word from you Alexander ?)
> 
> - always use mmap since it will work well on big RAM boxes too,
> and doesn't eat up all you system memory.
> 
> -in order to support MP3s and other fileformats decompress/convert this
> files first to a temporary WAV file and mmap() this into mem.
> 
> To speed up things even more you could save a the sample graph into
> a little file the first time you load the audio file, so that on subsequent
> loads, the 100MB audio file will "load" almost istantaneously in to mem.
> (thanks to mmap() ).
> 
> It would be possible to support direct disk streaming of MP3 files,
> but that is not a trivial task since you can't access an MP3 in
> random order, since the windowing filter depends on the previous
> filter state information.
> One way could be to store the filterstates of every mpeg frame into 
> a separate file and then reload the filter during seeks into the file. 
> But that would require to include an entire mp3 player with modified
> windowing filter code.
> 
> PS: Now if we could get one of these turntables recorded with special
> static waves (saw waves), we could add add turntable motion detection
> and get the same features as "finalscratch" on BeOS:
> scratching an audiofile in realtime using a real turntable.
> :-)

<shameless plug>

You might want to check out alsaplayer, http://www.alsa-project.org/~andy/
It does 'direct streaming from disk' for just about any format without
using mmap. It uses a ring buffer system and threading to cache data and
there is code for very low latency modes using SCHED_FIFO.
If you really want to emulate "finalscratch" just put the scratching mouse
functionality of terminatorX in some sort of plugin for alsaplayer. It
supports variable speed control (negative too, which is needed for
'scratching'). With a fast enough CDDA capable CDROM you can even
'scratch' your music CDs in realtime :-)

</shameless plug>

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

Re: [linux-audio-dev] streaming from disk to terminatorX added (via

[est]

Paul Barton-Davis discourseth:
> Benno writes:
> 
> >Since the kernel loads pages of the file into mem when they are
> >needed, it could cause audio-dropouts when working with low audio
> >buffer sizes (low latency) since, the playing thread might wait too
> >long for the kernel which tries to load the pages into mem.
> 
> >One trick to avoid this it to add a low priority thread , which does
> >basically read-ahead and read-behind, by accessing to pages before
> >and past the actual playing position.  It doesn't matter if this
> >thread blocks for a moment, since it doesn't play any audio data.
> >The audio thread will always find the needed pages in memory and will
> >not drop out.
> 
> i know that est@hyperreal.org will have something to say about this :)

Yes, I've been busy vacationing (which I still am :)

I don't see how mmap() can be reliable for this sort of thing.  Even
if you touch pages to bring them in, you could get unlucky.  Also,
this assumes we aren't mlocked to begin with which means that *any*
part of our process could be paged with resultant delays.  If we *do*
mlock() everything, the we need enough RAM for the entire sound file
and I'm not even sure exactly what would happen when doing the mmap().

> well, perhaps not, but he should. oolaboola (sp?)

Indeed..that's the usual translitteration. :)

> has been evolving
> toward some fairly sophisticated memory management to handle this kind
> of stuff.

Yes, and it's all ultimately based around intelligent advance `file'
(meaning `slow device') reads.  alsaplayer's buffering scheme may (as
Andy suggests) also be adequate.  oola has more support for loops and
marks but it doesn't yet handle negative rates.

Eric

Re: [linux-audio-dev] streaming from disk to terminatorX added (via mmap)

[Benno Senoner]

On Sun, 24 Oct 1999, Andy Lo A Foe wrote:

> 
> You might want to check out alsaplayer, http://www.alsa-project.org/~andy/
> It does 'direct streaming from disk' for just about any format without
> using mmap. It uses a ring buffer system and threading to cache data and
> there is code for very low latency modes using SCHED_FIFO.
> If you really want to emulate "finalscratch" just put the scratching mouse
> functionality of terminatorX in some sort of plugin for alsaplayer. It
> supports variable speed control (negative too, which is needed for
> 'scratching'). With a fast enough CDDA capable CDROM you can even
> 'scratch' your music CDs in realtime :-)
> 
>

I doubt it that a CDROM drive can keep up with a nervous scratcher.
:-)
The only solution is to keep in memory 100-200k samples before and past the
actual playing position, but I think reading backwards from a CDROM drive sucks
a lot.

regards,
Benno.

Re: [linux-audio-dev] streaming from disk to terminatorX added (via mmap)

[Benno Senoner]

On Sun, 24 Oct 1999, est@hyperreal.org wrote:

> I don't see how mmap() can be reliable for this sort of thing.  Even
> if you touch pages to bring them in, you could get unlucky.  Also,
> this assumes we aren't mlocked to begin with which means that *any*
> part of our process could be paged with resultant delays.  If we *do*
> mlock() everything, the we need enough RAM for the entire sound file
> and I'm not even sure exactly what would happen when doing the mmap().
> 
> > well, perhaps not, but he should. oolaboola (sp?)
> 
> Indeed..that's the usual translitteration. :)
> 
> > has been evolving
> > toward some fairly sophisticated memory management to handle this kind
> > of stuff.
> 
> Yes, and it's all ultimately based around intelligent advance `file'
> (meaning `slow device') reads.  alsaplayer's buffering scheme may (as
> Andy suggests) also be adequate.  oola has more support for loops and
> marks but it doesn't yet handle negative rates.
> 

Eric,
when not mlock()-ing the entire process (or at least the RT relevant data),
you have no chance to give ANY guarantee thet some pages could
not be swapped out.

What I'm trying to say: read() doesn't work better than mmap() in terms of
behaviour during swapping, because the kernel could easily swap out
your buffer where you read() in the data.
Your argument is not a valid argument to me.

Of course an even better solution than my "pagefaulter" thread ,
(but it will require root privileges), is to use a
thread which basically mlock() / munlock() the region around the 
actual playing position.
It's very easy to add to the pagefaulter thread:
instead of accessing to the pages just do the following in the while() loop:
(for example)

munlock() old range  ( old_start, old_len)

new_start=&samplebuffer[current_pos-100k];
new_len 0k;
( chekc the boundaries of start and len !)
mlock() new range (new_start,new_len)  


easy eh ?

SCHED_FIFO plus the above mlock()/munlock() is almost bulletproof.

normal scheduling plus the pagefaulter thread touching the pages is as reliable
as doing regular reads().
But here comes the linux low-latency problem:

In my tests using a buffer size of 100ms in terminator-X  (SCHED_FIFO) ,
I was able to play dropout-free audio on a 16MB RAM box,
running RH6.1 , X , KDE , netscape , 
10 processes which do  for(;;);   = CPU wasting loop
plus a cat /usr/bin/* >/dev/null running continuously 

of course 100ms is way too much for scratching in realtime,
but apply the lowlatency patches to the kernel and tune the disk and I'm sure
you can scratch trouble-free with 5ms latency or less.

I will add a feature to the pagefaulter thread which uses mlock()/munlock if
root privileges are available, so that even
Eric is satisfied.
:-)

someone still sceptic ?
:-)

PS: mlockall(MCL_CURRENT|MCL_FUTURE) is a bad idea because when you do the
mmap() of the large file the process tries to load all into mem,and my scheme
would not work. Better to use mlockall(MCL_CURRENT) and mlock()/munlock()
areas on demand.

regards,
Benno.
 

Re: [linux-audio-dev] streaming from disk to terminatorX added (via

[Andy Lo A Foe]

On Mon, 25 Oct 1999, Benno Senoner wrote:

> I doubt it that a CDROM drive can keep up with a nervous scratcher.
> :-)

Well, my Hitachi DVD-ROM does very well. I can get sustained playback 
at 500% (that's like ripping at 5 speed). Reverse playback works at up to
-400% reliably, that's enough for most 'scratching' purposes, unless the
DJs speed their records up 10x for a period of a few seconds :)

> The only solution is to keep in memory 100-200k samples before and past the
> actual playing position, but I think reading backwards from a CDROM drive sucks
> a lot.

Oh, actually I never read 'backwards' from a CD, or for that matter decode
an mp3 backwards. The ringbuffer is about 300K so that's enough for about
2 seconds of music.

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/