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

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

[Paul Barton-Davis]

 [ re: mmap ]

>Hmmmm.... Well I'd prefer a configure switch for the following
>reasons:
>
>- big endian machines

just FYI: my C++ libsoundfile uses mmap(), but still requires
applications to "read" the data. it is significantly faster than using
read(2) internally, however, so there might be an argument for using
mmap regardless of the endianness, and then using arch-dependent
macros to fetch the data from the mmapped area. for example, on a
little endian machine reading from a little endian RIFF/WAV file, the
macros are essentially no-ops. likewise for reading bigendian AIFF's
on bigendian machines. but for the opposite cases, the macros can do
the work necessary, and i think you'll still find mmap to be your
friend.

except, as est noted, if you're using mlockall ...

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

actually, no more than it would if you use a 4K memory buffer :) 

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

benno's code makes sure it *is* in RAM already. just not all of it
at one time.

--p

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

[Alexander König]

Paul Barton-Davis wrote:
> just FYI: my C++ libsoundfile uses mmap(), but still requires
> applications to "read" the data. it is significantly faster than using
> read(2) internally, however, so there might be an argument for using
> mmap regardless of the endianness, and then using arch-dependent
> macros to fetch the data from the mmapped area. for example, on a
> little endian machine reading from a little endian RIFF/WAV file, the
> macros are essentially no-ops.

No-ops? Do you mean you don't generate ANY code for this? If so: HOW?

<..>
> >- 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.
> 
> actually, no more than it would if you use a 4K memory buffer :)

??? Yeah sure, using a limited buffer will have the same effect but the
way tX currently does it is like the good ole trackers did it: it loads
the samples COMPLETELY in RAM so there is no disk-activity at all while
playing....

> >- 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...)
> 
> benno's code makes sure it *is* in RAM already. just not all of it
> at one time.

Yeah, you are right. I guess what I wanted to say was: If you mmap()
files instead of loading there's a lot of other stuff happening aside
for audio-rendering (you know like mmap()-code, fs-code, ide-code...)
Now if you have a lot of turntables and some effects enabled your CPU
may be pretty busy getting the audio ready for playback and that
additional code may be too much.. well still: it's just an assumption ;)

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

[From the Homer Quotables:]
 
I'll work from midnight to eight, come home, sleep for
five minutes, eat breakfast, sleep six more minutes,
shower, then I have ten minutes to bask in Lisa's love,
then I'm off to the power plant fresh as a daisy.

		-- Homer Simpson
		   Lisa's Pony

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

[Paul Barton-Davis]

In message <38151885.7A650570@42.fht-esslingen.de>you write:
>Paul Barton-Davis wrote:
>> just FYI: my C++ libsoundfile uses mmap(), but still requires
>> applications to "read" the data. it is significantly faster than using
>> read(2) internally, however, so there might be an argument for using
>> mmap regardless of the endianness, and then using arch-dependent
>> macros to fetch the data from the mmapped area. for example, on a
>> little endian machine reading from a little endian RIFF/WAV file, the
>> macros are essentially no-ops.
>
>No-ops? Do you mean you don't generate ANY code for this? If so: HOW?

sorry, not very accurate. for example:

       int16 foo;
       unsigned char *p;

       foo = get_little_endian_int16 (p)

on an LE machine, this is just:

       foo = *((int16 *) p);

on a BE machine, its a bit more complex.

the first case is what i meant by a "noop", not a literal NOOP.

>??? Yeah sure, using a limited buffer will have the same effect but the
>way tX currently does it is like the good ole trackers did it: it loads
>the samples COMPLETELY in RAM so there is no disk-activity at all while
>playing....

not so, unless you use mlockall. you mean, completely in VM. not quite
the same thing.

>> benno's code makes sure it *is* in RAM already. just not all of it
>> at one time.
>
>Yeah, you are right. I guess what I wanted to say was: If you mmap()
>files instead of loading there's a lot of other stuff happening aside
>for audio-rendering (you know like mmap()-code, fs-code, ide-code...)
>Now if you have a lot of turntables and some effects enabled your CPU
>may be pretty busy getting the audio ready for playback and that
>additional code may be too much.. well still: it's just an assumption ;)

unless you mlock(all) the pages on which your soundfile lives, there
is no reason why the CPU has to do anymore work in the mmap(2) case
than in the "malloc(3); read (2)" case, assuming that after mmap() you
touch every page of the mmapped-file (this makes it equivalent to the
"read" case, since there, the reading-in touched very page of the data
too). in both cases, a page may be paged out, and cause a page fault,
requiring the CPU to initiate a fetch. if its not paged out, no extra
cost either way.

--p

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

[David Olofson]

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

Well, decoding "audio style" signals into speed (or ratherposition) is
*exactly* what my decoding method does. Only, in this case it can
be simplified quite a bit. :-) (I have a carrier frequency to deal
with, and *very* high precision is required. Nice collection of
signal enhacers and trackers already, and I'm still working on it...)

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

Two alternatives I can think of right now;

1) A "ramp" (saw) wave.

2) Two sine waves (stereo), 90 degrees out of phase.

> and then the algorithm ?

1) Phase lock to the zero crossings.

2) "angle" = atan(left/right). Phase lock and count quadrant.

> couting the number of zero crosses/sign changes ?

1) Yes. (That's about all you can do in any easy way, due to
   the effect the analog cicuitry has on the saw wave...)

2) Yes, for the phase locking. The atan() gives the current
   position within the current quadrant, so you can use a low
   frequency waveform => very high upper speed limit.

> how o detect motion inversion ?

1) Check the ramp climb/fall tendency around the zero
   crossing. Be aware that the signal may not look all that
   much like a saw wave at high speeds!

2) The atan() fixes the high precision part. Check the
   right/left relation to see if you should count up or down
   in the zero crossings. (Note: The zero crossings are
   alternating between left and right; one for each quadrant
   crossing.) A simpler way (if you have nice signals) is to
   just check which one of +90 or -90 degrees places the new
   reading closest to the previous one.

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

Yes, but you'd better integrate some (reset when the "jump" is
detected!), or you may not get the result you expect. Next problem;
the jump won't be anything like sharp and easy to detect in real
life, at least not if you're looking for changes in the signal on "DC
dynamis level" at the same time...

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

Hmm... The horsepower is in the *box*. Real time support is the
"only" special feature needed for this - and we're probably beating
them on that by now.

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

Why not? As far as I can see, it's really more about performance and
being able to do it reliably, than about tons of features that will
take years to hack. That is, no one without a real OS performance
edge can compete. Go for it! :-)


//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: [linux-audio-dev] Re: streaming from disk to terminatorX added (via

[Alexander König]

First of: thanks for explaining all of this... I was looking through the
"api-glasses" and not at what *really* happens (at pageing level) I
guess.

Paul Barton-Davis wrote:
<..>
[byteswapping]
> on an LE machine, this is just:
> 
>        foo = *((int16 *) p);
> 
> on a BE machine, its a bit more complex.
> 
> the first case is what i meant by a "noop", not a literal NOOP.

Yeah well was thinking "BE" when I said that would need a little more
work. You know currently (on BE machines) tX byteswaps the (whole) data
while loading. Now this of course is not possible with mmap(). This
means the loop that has to be done in realtime looks like this:
with malloc()/read(): 
	- process_sample
	- bytes_swap_sample // for audiodevice
with mmap():
	- bytes_swap_sample //from wav 
	- process_sample 
	- byte_swap_sample // for audiodevice

Well, after considering what "process_sample" actually means (a LOT of
code ;) you are right: byteswapping is nearly a noop, even on BE
machines...

<..>
> >the samples COMPLETELY in RAM so there is no disk-activity at all while
> >playing....
> 
> not so, unless you use mlockall. you mean, completely in VM. not quite
> the same thing.

Yes, Sorry :)

<..>
> unless you mlock(all) the pages on which your soundfile lives, there
> is no reason why the CPU has to do anymore work in the mmap(2) case
> than in the "malloc(3); read (2)" case, assuming that after mmap() you
> touch every page of the mmapped-file (this makes it equivalent to the
> "read" case, since there, the reading-in touched very page of the data
> too). in both cases, a page may be paged out, and cause a page fault,
> requiring the CPU to initiate a fetch. if its not paged out, no extra
> cost either way.

Yes! Thanks.

So that means:

- Let's say I have a machine that can easily store a certain
sample-setup completely without swapping in memory (with malloc/read).
Now let's say instead of malloc/read I mmap() and "read" through the
whole file before playing the first time (to display the data). Then the
complete file will be in memory just like with malloc/read (still
assuming it fits in memory). This way there will be no disk-activity
while playing, either way, right?

- to get that more precise: The swap-out criteria for a mmap()'ed page
and a malloced()-page (not mlocked()) are the same, right?

Then I agree: mmap()ing wav-files is definitely the better way of doing
it. Thanks for makeing that clear. Still there are those other problems
that would keep me (for now!) from using the mmap-way as the default
way:
- I would have to drop sox/mpg123 (unmapable ;) which would really annoy
a lot of people. Although that could be helped by somehow including
Andy's "magic" mp3-decoding - but I have no idea how complex this would
be.
- And I have no idea wether mmap()ing files is available on other
platforms (where tX will be ported to) - this is of course just a lack
of knowledge
- The "builtin" wav-header analyzing routines are based on wavtools and
they are somewhat problematic. Or no they're not but they force you to
use 16Bit/44Khz/Mono Wav files only and that's a little bit annoying
which is why I went on an used sox... Btw could give me a link to your
libsoundfile?

Well there are solutions to all of these points I guess. We'll see.
Thanks again!

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

[From the Homer Quotables:]
 
Twenty of the suckiest minutes of my life.

		-- Homer Simpson
		   Burns, Baby Burns

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

[Andy Lo A Foe]

On Mon, 25 Oct 1999, Benno Senoner wrote:

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

I have volunteered to port the software to Linux (the original author of
finalscratch lives in my town and I know him from BeOS meetings). Haven't
heard anything back. I'm starting to think the decision to port to Linux 
is more political than technical :)

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

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

[Jaroslav Kysela]

On Mon, 25 Oct 1999, Paul Barton-Davis wrote:

> In message <38151885.7A650570@42.fht-esslingen.de>you write:
> >Paul Barton-Davis wrote:
> >> just FYI: my C++ libsoundfile uses mmap(), but still requires
> >> applications to "read" the data. it is significantly faster than using
> >> read(2) internally, however, so there might be an argument for using
> >> mmap regardless of the endianness, and then using arch-dependent
> >> macros to fetch the data from the mmapped area. for example, on a
> >> little endian machine reading from a little endian RIFF/WAV file, the
> >> macros are essentially no-ops.
> >
> >No-ops? Do you mean you don't generate ANY code for this? If so: HOW?
> 
> sorry, not very accurate. for example:
> 
>        int16 foo;
>        unsigned char *p;
> 
>        foo = get_little_endian_int16 (p)
> 
> on an LE machine, this is just:
> 
>        foo = *((int16 *) p);
> 
> on a BE machine, its a bit more complex.

Not very much:

	#include <byteswap.h>

	foo = bswap_16(*((int16 *)p));

The defined macros from GLIBC already does byte swapping in the best way
for given architecture.

							Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

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

[Maarten de Boer]

Any wrote
> 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 ;-)

I'd say it is fairly easy to take an old turntable and a mouse,
and connect one of the 2 mouse sensors to the turntable. Or,
I guess this should also work: place a turntable-dish on the 
step-motor of a 5 1/4 inch disk drive. I think you can get 
pulses from the motor when you move it.

Maarten