streaming from disk to terminatorX added (via mmap)

streaming from disk to terminatorX added (via mmap)

[Benno Senoner]

for those that are interested:

Yesterday I went on terminatorX's (the scratching app)  homepage (
http://termX.cjb.net ), and read in the FAQ that it doesn't support streaming
from disk, because it would require a complete redesign of the app.
But fortunately Alexander was wrong:
:-)
use mmap and it's powerful caching algorithms.

I added from disk streaming because I think that many users
running on low memory boxes could run into big troubles
when scratching large audiofiles.
( The audiofile could not fit into the swaparea, and the
loading of the file could take very long, since it has to be swapped out,
etc.)

the patch is here:

http://www.gardena.net/benno/linux/terminatorX-3.2-mmap.patch


Basically what I changed is:
instead of loading the file into RAM, I mmap() the entire file 
into memory.
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.

With this approach I was able to scratch a 100MB mono file,
on a 16MB RAM box, running X , KDE and Netscape (what a pain to load netscape :-) ) !
(using SCHED_FIFO scheduling)

ATTENTION:

sometimes: there might  occur audio dropouts during streaming from disk,but
that is not the fault of the app but, it's a common problem of Linux.

For dropout free low-latency performance apply the low-latency patches
at
http://www.gardena.net/benno/linux/audio

and tune your EIDE as described in the page
( /sbin/hdparm -c 1 -m 8 -u 1 -d 1 /dev/hda  for example)

Linux 2.4 will contain the low-latency patches as default,
and this will be a great benefit for realtime apps like terminator-X.

I hope that scratchers running on low RAM boxes will enjoy the mmap patch !
:-)

BUGS:

- the 44byte WAV header isn't skipped
- mpg123 and sox support doesn't work (would require decompressing
to a temporary file)
- might not work on BIGENDIAN boxes

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

regards,

Benno.
sbenno@gardena.net

Re: streaming from disk to terminatorX added (via mmap)

[David Olofson]

On Sun, 24 Oct 1999, Benno Senoner wrote:
> 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.
> :-)

Uhm, I have just developed a sensor decoding method that could be
useful for this. It's probably overkill, as it's accurate to some 128
bits/period of the input signal with input signals of around that
resolution. It's just that I most probably can't release the
details... :-(

Anyway, I have a clue about how to do it, so I could give some hints
if needed.

And there are other ways than a special LP. For example, a quadrature
decoder; get two reflective optisensors (UV LED + photodiode in a
single package - handy! :-), and use an encoder stripe around the
turntable disk. The encoder strip should look like this:

Sensor 1: ####    ####    ####    ####    ####
Sensor 2:   ####    ####    ####    ####    ####

Note: 90 degree phase diff!

Then run the "sensor 1" signal into the U/_D input of a binary
counter. (Standard chip - use 4xxx chips [CMOS], as they're less
sensitive to Vcc errors. Do *not* use buffered chips as triggers for
reading the sensors - they can start to oscillate and fry!) The
"sensor 2" signal goes to the count input of the chip. The chip is
then hooked up to a parallel port or something, so that you can read
the current value.

Of course, you may also rip out the electronics from a mouse.
(Preferably a PS/2 one, as they have 30-150 Hz update rate, as
opposed to 10-30 for serial mice...) That's two channels and some
buttons + decoder and interface - and there are drivers. :-) Remove
the LEDs and photodiodes/transistors from the mouse PCB, and replace
them with wires to the new detectors.


//David


 ·A·U·D·I·A·L·I·T·Y·   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    ·Rock Solid                                      David Olofson:
    ·Low Latency    www.angelfire.com/or/audiality   ·Audio Hacker
    ·Plug-Ins            audiality@swipnet.se        ·Linux Advocate
    ·Open Source                                     ·Singer/Composer

Re: streaming from disk to terminatorX added (via mmap)

[Juhana Sadeharju]

>From:   Benno Senoner <sbenno@gardena.net>
>
>- the 44byte WAV header isn't skipped

I suggest the full parse of WAV file because some editors put extra
chunks to end. Actually a full parse is not needed because we need
just to find the offset and length for mmapping, but don't just skip!

Yours,

Juhana

Re: streaming from disk to terminatorX added (via mmap)

[Alexander König]

Hi,

First of: thanks for your patch Benno! Now I applied it but I have a
problem... on my system I get a "no such device"-error. And all my
(mmap)manpage says is: Svr4 documents additional error codes ENXIO and
ENODEV. Do you have any idea what's wrong with my system? I am sorry if
this is a dumb question - I've never used mmap....

Now for the replying:

Benno Senoner wrote:
> for those that are interested:

I am :)

> Yesterday I went on terminatorX's (the scratching app)  homepage (
> http://termX.cjb.net ), and read in the FAQ that it doesn't support streaming
> from disk, because it would require a complete redesign of the app.
> But fortunately Alexander was wrong:
> :-)

Hehe, good to know. Yeah I didn't know how easy this is - dumb me ;)

<..>
> http://www.gardena.net/benno/linux/terminatorX-3.2-mmap.patch

Yeah, ok I have it. Now the problem is I've been working on tX quite a
lot lately and a lot of things have changed. But from looking at your
patch it looks like it should be possible to port your changes to the
new version easily. Please send me a mail, Benno, if you want to have
access to the CVS repository and maybe take a look at the new stuff
yourself. IMHO it would be cool if we could integrate your patch into
the sources, maybe wrapped into some #ifdef USE_MMAP / #endif statements
so the user could decide whether to use mmap or not with a configure
switch....

> Basically what I changed is:
<..>
> With this approach I was able to scratch a 100MB mono file,
> on a 16MB RAM box, running X , KDE and Netscape (what a pain to load netscape :-) ) !
> (using SCHED_FIFO scheduling)

Cool. That definitely helps a lot of people! mmap is really amazing ;)

<..>
> BUGS:
> 
> - the 44byte WAV header isn't skipped
> - mpg123 and sox support doesn't work (would require decompressing
> to a temporary file)
> - might not work on BIGENDIAN boxes

Well, AFAIK the plain tX 3.2 doesn't work on BIGENDIAN machines
either... (sorry big endian users) I plan to get that fixed before I
release the new version... Oh with mmap()-ed files we need to do the
BIGENDIAN-de/encoding right before actually processing a block and not
the way it's done now while loading. That should be possible... oh but
the usual big endian machines have enough memory, right? ;)

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

Hmmmm.... Well I'd prefer a configure switch for the following
reasons:

- big endian machines
- the next release of tX will allow you to load MANY (as many as you
want) samples in multiple turntables. If all these are mmap'ed files I
guess your disk-head will jump around like mad when playing.
- And the next release will no longer record into memory (yeah for the
same reason you introduced mmap(), Benno ;) but straight to harddisk -
now that would cause a lot of harddisk action with mmap()ed files too...
- With 6 to 8 tables playing my system is pretty loaded in these cases
it might be a performance win to have the samples in the memory
already.. (well these are just assumptions - we should get your code
applied to the new stuff to see whether it's true...)
- I don't want to drop mp3 and sox support (I know a LOT of people use
this)

So maybe you agree it would make sense giving the user the choice
whether to use mmap or not. And for the sake of mp3-compability I'd even
keep the loading-behaviour as the default behaviour. Well at least for
now...

> -in order to support MP3s and other fileformats decompress/convert this
> files first to a temporary WAV file and mmap() this into mem.

That'll work of course but I guess people with machines with enough mem
might prefer loading the file...

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

Thats a cool idea. Now if that mmap() stuff works nicely with kernel 2.4
and mp3 would work with it (see below) it really would make sense to
switch to mmap completely... 

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

It's done already! Take a look at Andy's brilliant alsaplayer:
http://www.alsa-project.org/~andy/

He does dynamic-mp3 decoding and it works beautifully...

(Hi Andy, I wrote that before I saw you already replied...)

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

I've never seen finalscratch. But how do these static waves you're
talking about work? I'd really like to know how that works... Btw I use
a real turntable for scratching with tX BUT you cannot use it like a
real turntable (well while scratching you can, it wouldn't make sense if
you couldn't) but you still have to press space... I've prepared a
html-page (with some photos and explanation) for my tX-site already and
I'd say it finished. I plan to put it up on the page tomorrow... maybe
you want to take a look at that.

So I'm looking forward to hearing from you again, Benno

Bye,
Alex
-- 
_______________________________________________________________________
                            Alexander König - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
Could this be the best day of my life?

                -- Homer Simpson
                   Homer the Heretic

Re: streaming from disk to terminatorX added (via mmap)

[Benno Senoner]

On Mon, 25 Oct 1999, Alexander König wrote:
> Hi,
> 
> First of: thanks for your patch Benno! Now I applied it but I have a
> problem... on my system I get a "no such device"-error. And all my
> (mmap)manpage says is: Svr4 documents additional error codes ENXIO and
> ENODEV. Do you have any idea what's wrong with my system? I am sorry if
> this is a dumb question - I've never used mmap....

hmmm that is strange ...
where exactly after the mmap ?
try to check if MYFILESIZE is a valid value (page aligned size of the file),
if fileno(wav_in.handle) is a valid value etc

> 
> Yeah, ok I have it. Now the problem is I've been working on tX quite a
> lot lately and a lot of things have changed. But from looking at your
> patch it looks like it should be possible to port your changes to the
> new version easily. Please send me a mail, Benno, if you want to have
> access to the CVS repository and maybe take a look at the new stuff
> yourself. IMHO it would be cool if we could integrate your patch into
> the sources, maybe wrapped into some #ifdef USE_MMAP / #endif statements
> so the user could decide whether to use mmap or not with a configure
> switch....


> 
> > Basically what I changed is:
> <..>
> > With this approach I was able to scratch a 100MB mono file,
> > on a 16MB RAM box, running X , KDE and Netscape (what a pain to load netscape :-) ) !
> > (using SCHED_FIFO scheduling)
> 
> Cool. That definitely helps a lot of people! mmap is really amazing ;)
> 
> <..>
> > BUGS:
> > 
> > - the 44byte WAV header isn't skipped
> > - mpg123 and sox support doesn't work (would require decompressing
> > to a temporary file)
> > - might not work on BIGENDIAN boxes
> 
> Well, AFAIK the plain tX 3.2 doesn't work on BIGENDIAN machines
> either... (sorry big endian users) I plan to get that fixed before I
> release the new version... Oh with mmap()-ed files we need to do the
> BIGENDIAN-de/encoding right before actually processing a block and not
> the way it's done now while loading. That should be possible... oh but
> the usual big endian machines have enough memory, right? ;)

Ok skipping the WAV header is really easy , just add the offset to samplebuffer
before you start the engine, but subtract the value before doing any free()
or you will get nice segfaults because you are trying to free inexistent memory
areas.
For BIGENDIAN boxes, I'd suggest to do the byte swapping just before you process
the data, the overhead is very little compared to all the rest.


> 
> > 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.
> 
> Hmmmm.... Well I'd prefer a configure switch for the following
> reasons:
> 
> - big endian machines

use byte swapping on the fly

> - the next release of tX will allow you to load MANY (as many as you
> want) samples in multiple turntables. If all these are mmap'ed files I
> guess your disk-head will jump around like mad when playing.

the trick is the following:
actually I access to the pages about 10times / sec.
With multiple streams to reduce overhead you have to avoid
that all the files are accessed  10-20times/sec, but you have
to do this sequentially and must use larger in-memory buffers:
that means you should "read" the memory buffers at least
in 128k-256k blocks to keep the disk seeking down.

I esperimented with streaming of 60 mono ( 44khz 16bit) tracks from disk
and I had to use at least 1MB buffer per track to keep things somewhat
reliable.
( PII400 + 256MB RAM + IBM 16GB EDIE HD)
 

> - And the next release will no longer record into memory (yeah for the
> same reason you introduced mmap(), Benno ;) but straight to harddisk -
> now that would cause a lot of harddisk action with mmap()ed files too...
> - With 6 to 8 tables playing my system is pretty loaded in these cases
> it might be a performance win to have the samples in the memory
> already.. (well these are just assumptions - we should get your code
> applied to the new stuff to see whether it's true...)

How du you plan to keep into mem 8 files of 20MB in len (4min mono file)
= 160MB, not everyone has that amount of ram on his box.

Trust me: smart mmap() + mlocking() will work well and reliably on 8 tracks
while saving the mix on the disk, using no more that 500kb-1Mb per track.


> - I don't want to drop mp3 and sox support (I know a LOT of people use
> this)

for mp3:
if this is really true that Andy has managed to play mp3s backwards *CORRECTLY*
without any distortion, then if I were You, I would include his mp3 code.

Andy are you saving filterstate information in your alsa player ?
that means what happens if I play the file from the beginning to almost the end,
and then I reverse the playing direction and play the file until it reaches the
start ?
Does all this process sound 100% correctly ?
It would require to save the filter state of every played MPEG frame right ?


SOX: you can provide 2 methods: direct in mem loading or converting to a
temporary file and then mmap() the file into mem.
let's the user take the choice.

> 
> So maybe you agree it would make sense giving the user the choice
> whether to use mmap or not. And for the sake of mp3-compability I'd even
> keep the loading-behaviour as the default behaviour. Well at least for
> now...

IMHO on low mem boxes, it's better to first decompress the mp3 to a temporary
wav file and then mmap() this into mem, instead of loading all into mem
(which would swapout almost the entire file to the swaparea), and would take
even more time than the pure decompressing of the mp3 to the wav file.
Remember in your case the probability that swapping might occur is much higher
since your file in memory used up almost all physical memory.
Instead in the mmap()ed case there is still physical memory free for other
things, since mmap() buffers only the most recent pages.

> 
> > -in order to support MP3s and other fileformats decompress/convert this
> > files first to a temporary WAV file and mmap() this into mem.
> 
> That'll work of course but I guess people with machines with enough mem
> might prefer loading the file...

Yea, provide both, as you can see from the patch, the pure mmap()ing of
the file requires very little effort: instead of malloc()ing a memory region 
and read the file into mem, just mmap() the file in that region.

> 
> > 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() ).
> 
> Thats a cool idea. Now if that mmap() stuff works nicely with kernel 2.4
> and mp3 would work with it (see below) it really would make sense to
> switch to mmap completely... 

mmap() already worked nicely with most linux kernels, and in 2.4 it will work
even better due to the improved LRU paging algorithms.

> 
> > 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.
> > :-)
> 
> I've never seen finalscratch. But how do these static waves you're
> talking about work? I'd really like to know how that works... Btw I use
> a real turntable for scratching with tX BUT you cannot use it like a
> real turntable (well while scratching you can, it wouldn't make sense if
> you couldn't) but you still have to press space... I've prepared a
> html-page (with some photos and explanation) for my tX-site already and
> I'd say it finished. I plan to put it up on the page tomorrow... maybe
> you want to take a look at that.
> 
> So I'm looking forward to hearing from you again, Benno

Finalscratch I have not the link handy 
 look at http://www.be.com   or http://www.lebuzz.com and search
for finalscratch in the audio apps section and you will find the link.
(or alternatively try a search engine like google or so, should find the URL
too)

Basically as far I understand they sample (using the soundcard) a static wave
recorded on the turntable and compute the actual rotational speed.
Then just feed this value to the tX engine, and your
mp3 on-turntable scratcher is here.
:-)

In the next days I will add mlock()/munlock() support to tX let's see it there
are any benefits during high system load.


Alex, if you want to mail me privately you can mail me in german too,
( I'm from Suedtirol  :-)  )

Benno.

Re: streaming from disk to terminatorX added (via mmap)

[Benno Senoner]

On Sun, 24 Oct 1999, David Olofson wrote:
> On Sun, 24 Oct 1999, Benno Senoner wrote:
> > 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.
> > :-)
> 
> Uhm, I have just developed a sensor decoding method that could be
> useful for this. It's probably overkill, as it's accurate to some 128
> bits/period of the input signal with input signals of around that
> resolution. It's just that I most probably can't release the
> details... :-(
> 

David, your solution looks nicely,
but I'm more for a plug-n-play solution:

2 turntable players
2 soundcards
1 PC loaded with mp3

use the 2 soundcard's inputs to detect turntable speed (py playing the static
waves on the turntable),
use the 2 audio outputs for the mix and prelisten (phones) channel.

IMHO the precision provided by sampling the turnables's static waves
is enough to get decent scratches, and the use of a "noise gate" when
the turntable is rotating at default speed will give you the final touch of
perfection.
:-)

David, I'cant remember but what would be the optimal method to detect
the speed of the turntables via audio input ?

form of the wave ?
SAW WAVE , which frequency ?

and then the algorithm ?
couting the number of zero crosses/sign changes ?
how o detect motion inversion ?
through looking at the resulting waveform ? :
if the next value is less than the previous 
AND you are not at end of the period (the jump is too big),
then you detected motion inversion.
right ?

The finalscratch people seemed wrong to think that only BeOS can provide
the horsepower to run a scratch-mp3s-on-turntable engine.

Seems that linux , will soon even begin to eat marketshare into the DJ sector.
:-)
( As David said: your next console could be powered by a GPLed audio engine
running Linux  :-)  )

Benno.

Re: streaming from disk to terminatorX added (via mmap)

[Andy Lo A Foe]

On Mon, 25 Oct 1999, Benno Senoner wrote:

> for mp3:
> if this is really true that Andy has managed to play mp3s backwards *CORRECTLY*
> without any distortion, then if I were You, I would include his mp3 code.
> 
> Andy are you saving filterstate information in your alsa player ?

No

> that means what happens if I play the file from the beginning to almost the end,
> and then I reverse the playing direction and play the file until it reaches the
> start ? Does all this process sound 100% correctly ?

Yes

> It would require to save the filter state of every played MPEG frame right ?

It works like this: the ringbuffer I use is segmented;

		
	disk/cdrom based mp3/cdda/wav/etc		
		|
		|
	audio decoder thread
	decodes mp3/cdda/wav/etc
	fills the framebuffer segments
		|
		|

[|---------|---------|---------|----------|---------|] ringbuffer
             segment			
					|
					|
				audio reader thread
				reads framebuffer segments
				and feeds the soundcard
					|
					|
				    soundcard	


A segment holds a number of decoded frames (usually 2 or 3) and also
remembers the number of the first frame. So lets say we want to play 
a mp3 backwards starting at frame 1000. The tricky part is to keep the
ringbuffer full with the right frames all the time. As soon as one segment
is used up by the audio reader thread it releases a semaphore on which the
audio decoder thread is blocking on. The audio decoder thread wakes up and
check if there are any segments that needs to be filled. But wait you say,
what if you need to fill a segment with frames 1000 to 998? Decoding frame
1000, then 999 and then 998 won't work because of the way mp3s are
encoded. What do you do then? You seek to frame 995 and start decoding
from there. You throw all data away up to and including frame 997. By this
time your mp3 decoding engine is recovered from the 'seek' operation. Now
you store the next 3 frames in your ringbuffer. The audio reader thread,
when detecting negative speed, simply reads a segment backwards so in
this case it starts at frame 1000. The segment before the current one
must contain frame 995 to 997 (first jump to frame 992, decode 3
frames and discard them, decode the needed data), and so on...
The decoder thread is also a couple of segments ahead of the reader
thread. So when you do rapid positive and negative speed switching
(scratching) the decoder thread is actually idling since none of the
segments get discarded. 

Comments? :)

Andy

PS. On my lowly PII 233 I can actually play quite a few mp3's (tested with
7), each with different speed, simultaneously. This is with ALSA and a Trident
4DWave NX card that does hardware mixing.
--
AlsaPlayer, http://www.alsa-project.org/~andy/

Re: streaming from disk to terminatorX added (via mmap)

[Alexander König]

Hi again...

Benno Senoner wrote:
> > problem... on my system I get a "no such device"-error. And all my
> > (mmap)manpage says is: Svr4 documents additional error codes ENXIO and
> > ENODEV. Do you have any idea what's wrong with my system? I am sorry if
> > this is a dumb question - I've never used mmap....
> 
> hmmm that is strange ...
> where exactly after the mmap ?
> try to check if MYFILESIZE is a valid value (page aligned size of the file),
> if fileno(wav_in.handle) is a valid value etc

Oops - just as I expected a *really* dumb question. I changed the
configure script to use mpg123/sox as default if available and that of
course does not work with mmap()... well a --enable-wavonly fixed this
:( Sorry! Oh yeah: it works beautifully on big mem machines ;) So I
guess "no such device" just tells me this FILE* is not on a device (as
it is a pipe)... Yes, see my face red.

<..>
> For BIGENDIAN boxes, I'd suggest to do the byte swapping just before you process
> the data, the overhead is very little compared to all the rest.

Yeah - while discussing this with Paul I actually came to the same
conclusion. It's a joke compared to the rest that's done with the
sample...

<..>
> use byte swapping on the fly

Agreed :)

<..>
> I esperimented with streaming of 60 mono ( 44khz 16bit) tracks from disk
> and I had to use at least 1MB buffer per track to keep things somewhat
> reliable.
> ( PII400 + 256MB RAM + IBM 16GB EDIE HD)

Hey we should try to get the mmap()-code to the new tX soon - I'd really
like to see this :)

> How du you plan to keep into mem 8 files of 20MB in len (4min mono file)
> = 160MB, not everyone has that amount of ram on his box.

Yeah well, from it's design-idea you actually have shorter and looping
samples (yes and maybe one or two big ones) as only then you can
actually sync those turntables nicely... but: you are right!

> Trust me: smart mmap() + mlocking() will work well and reliably on 8 tracks
> while saving the mix on the disk, using no more that 500kb-1Mb per track.

Yeah. Accepted. Let me see it ;)

> for mp3:
> if this is really true that Andy has managed to play mp3s backwards *CORRECTLY*
> without any distortion, then if I were You, I would include his mp3 code.

Yes actually I'd like to have that... Hi, Andy ;) But if you take a look
at the current tX (it should be avialable via anonymous CVS from 
:pserver:terminatorX@rhlx01.fht-esslingen.de:/cvs/terminatorX
oh, if you check it out: first step: press "add turntable" ;)
you'll see: I have a lot of other things to do for tX too :( But having
a tX that would allow mmap()ing mono-wavs and streaming mp3s with Andy's
code and the ability to load other audioformats via sox sounds extremly
cool :)

<..>
[real turntables]
> Basically as far I understand they sample (using the soundcard) a static wave
> recorded on the turntable and compute the actual rotational speed.
> Then just feed this value to the tX engine, and your
> mp3 on-turntable scratcher is here.
> :-)

Damn and I just destroyed the motor of my turntable for terminatorX...

> In the next days I will add mlock()/munlock() support to tX let's see it there
> are any benefits during high system load.
> 
> Alex, if you want to mail me privately you can mail me in german too,
> ( I'm from Suedtirol  :-)  )

Yes actually I will do that so we can chat about CVS and moving your
code into the next release...

Bye, Alex
-- 
_______________________________________________________________________
                            Alexander König - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
I don't care if Ned Flanders is the nicest guy 
in the world.  He's a jerk -- end of story.

		-- Homer Simpson
		   When Flanders Failed

Re: streaming from disk to terminatorX added (via mmap)

[Andy Lo A Foe]

On Tue, 26 Oct 1999, Alexander [iso-8859-1] König wrote:

> Yes actually I'd like to have that... Hi, Andy ;) But if you take a look

Hi Alex :)

> at the current tX (it should be avialable via anonymous CVS from 
> :pserver:terminatorX@rhlx01.fht-esslingen.de:/cvs/terminatorX
> oh, if you check it out: first step: press "add turntable" ;)
> you'll see: I have a lot of other things to do for tX too :( But having
> a tX that would allow mmap()ing mono-wavs and streaming mp3s with Andy's
> code and the ability to load other audioformats via sox sounds extremly
> cool :)

Here's my idea of a cool plugin. Put a representation of a Vinyl record on
the screen. Add 'artifical' markers to the surface so you can actually see
the record moving at 33RPM, 45RPM or whatever. Now grab the record with
your mouse and start scratching! I know it's not going to be very accurate
but it's gonna be hella cool nonetheless ;-)

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

Re: streaming from disk to terminatorX added (via mmap)

[Benno Senoner]

On Tue, 26 Oct 1999, Andy Lo A Foe wrote:

> A segment holds a number of decoded frames (usually 2 or 3) and also
> remembers the number of the first frame. So lets say we want to play 
> a mp3 backwards starting at frame 1000. The tricky part is to keep the
> ringbuffer full with the right frames all the time. As soon as one segment
> is used up by the audio reader thread it releases a semaphore on which the
> audio decoder thread is blocking on. The audio decoder thread wakes up and
> check if there are any segments that needs to be filled. But wait you say,
> what if you need to fill a segment with frames 1000 to 998? Decoding frame
> 1000, then 999 and then 998 won't work because of the way mp3s are
> encoded. What do you do then? You seek to frame 995 and start decoding
> from there. You throw all data away up to and including frame 997. By this
> time your mp3 decoding engine is recovered from the 'seek' operation. Now
> you store the next 3 frames in your ringbuffer. The audio reader thread,
> when detecting negative speed, simply reads a segment backwards so in
> this case it starts at frame 1000. The segment before the current one
> must contain frame 995 to 997 (first jump to frame 992, decode 3
> frames and discard them, decode the needed data), and so on...
> The decoder thread is also a couple of segments ahead of the reader
> thread. So when you do rapid positive and negative speed switching
> (scratching) the decoder thread is actually idling since none of the
> segments get discarded. 
> 
> Comments? :)

Ok, but what are then the general rule for decoding mp3 backwards: 
assume that you are at frame n:

point1:
decode frames: n-5 , n-4 n-3 , n-2 , n-1 , n  ( 6 frames)
throw away frames n-5,n-4,n-3
fill buffers with frames n-2 , n-1 , n  (this is thwe usable data)
n=n-3
return to point 1

right ?
(correct me pleasse if I'm wrong)

of course playing backward requires 2x the CPU horsepower, but with today's CPUs
combined with optimized x86 assembly code like the mpg123's one , this is not a
major problem except if you want to decode lots of tracks backwards.

regards,
Benno.