geekmaster's sound demo thread

[geekmaster]

Here, I will post a series of sound demos for the eink kindles (except the soundless K4). To begin, I present here a simple sound demo with relatively little code compared to other sound programs, and it even works on all kindles I tested it on (and probably the Raspberry Pi too).

geekmaster's noisy rhythms audio demo

This simple kindle sound demo plays a noisy rhythm on your eink kindle speakers (or headphones). To play this sound demo, just download and extract "noisy" (below), then copy it to your kindle USB drive, then run it (SSH, or with a launcher). It will stop automatically when finished.

Yeah, it is really nothing fancy, but now you can use your kindle to annoy others in the room with you.

The source code:

Spoiler:

PHP Code:

//====================================================
// noisy 1.0 - geekmaster's noisy rhythms audio demo
// Copyright (C) 2012 by geekmaster, with MIT license:
// http://www.opensource.org/licenses/mit-license.php
// with thanks to twobob for figuring out kindle sound
//----------------------------------------------------
// Tested on DX,K3,K5main.
//----------------------------------------------------
#include <stdio.h>
#include <asoundlib.h>

int main(void)
{
    unsigned int i,j;
    unsigned char buf[1024]; // play buffer
    snd_pcm_sframes_t fc;   // frame count
    snd_pcm_t *hp;         // play handle

    printf("geekmaster's noisy rhythms audio demo\n");
    snd_pcm_open(&hp,"default",SND_PCM_STREAM_PLAYBACK,0);
    snd_pcm_set_params(hp,SND_PCM_FORMAT_U8,
        SND_PCM_ACCESS_RW_INTERLEAVED,1,8000,1,500000); // 0.5sec
    for (i=0;i<256;i++) {
        for (j=0;j<sizeof(buf);j++) buf[j]=(random()&3)*i*350;
        fc=snd_pcm_writei(hp,buf,sizeof(buf));  // play buffer
        if (fc<0) fc=snd_pcm_recover(hp,fc,0); // error recovery
    }
    snd_pcm_close(hp);
    return 0;
} 


After cross-compiling the latest 1.0.25 ALSA sound library on my linux host PC (from source, with static-linking support), I used it to compile "noisy.c" with this command:

arm-linux-gcc -o noisy noisy.c -lasound

Geekmaster "noisy rhythms" Demo,
Sound Synthesis Algorithm,
Theory of Operation:

Spoiler:

The C "random()" function returns a random positive integer value (including 0). Normally you limit it to a range by truncating it. In this case, the "&3" keeps only the bottom two bits (giving random values in the range 0-3).

The outer "i" loop is repeated 256 times, and each iteration plays a 1024-byte sound buffer after it is filled with "amplitude modulated" random numbers by an inner "j" loop.

In the inner "j" loop, the buffer gets filled with 1024 2-bit random numbers that have been multiplied by (i*350). This multiplication changes (modulates) the maximum value of the result (i.e. the peak amplitude of the waveform in the buffer). In this case, i*350 causes the max value to be greater than 255 in many cases, so when the value is truncated to 8-bits and stored into a 1-byte sound buffer position, it gets "distorted" in a way that causes some very large numbers to become small (quiet).

Because the amplitude modulator control variable "i" sweeps from 0-255 while this demo plays, each 1024-byte buffer (short time period of random "hissing" noise) gets its volume set to a different "constrained random" value. I chose different multiplier (distortion/gain) values until I found a value (350) that sounded pleasing with a nice syncopated periodicity, giving it a not-so-annoying semi-percussive rift.

The sample rate is 8000 samples per second, which means that if you call one play of the 1024-byte sound buffer a "beat", then this program plays 256 beats of almost 8 beats per second. Each beat plays at a different sound volume, creating the "semi-percussive" sound. Changing the "350" multiplier changes both the depth of distortion and the perceived repetition rate of the slowly varying distortion pattern. This perceived repetition is an audio interference pattern similar in nature to the visual interference (moire) patterns in some of my eink animation demos.

Now that we have simple audio support for native mode programs (on all eink kindles except the soundless K4), our next step is to integrate it into gmplay (geekmaster's kindle video player). Then we get to encode movies with sound. Then YOU get to play (and listen to) those movies.

EDIT: K4 owners, never fear, there are plans to add USB sound support to your K4 too, using the same methods already being used for the Nook Simple Touch (a short $0.97USD USB host mode cable, a $1.35USD USB sound stick, and some free software). We just need to borrow a little code from the Nook Simple Touch forums. I ordered my USB host cables and USB sound sticks at the links above (with free international shipping).

The download files:

[geekmaster]

Building sound demos like "noisy" on the kindle with tcc would require some missing files needed for "tccmake noisy -lasound" to succeed. These files could probably be copied to the kindle from the host PC cross-compiler "include" and "alsa" directories. "Somebody" really ought to try that at some point (in the near future).

[twobob]

HA! Quality.

*Goes off to test

Okay first thoughts. by calculating the realtime speed of the bits at your chosen rate you could swap in fixed sections of 0's modulo something.
I see you already use &3 so something of this order again I would imagine.

That would still be programmatically tidy and would create real percussive effects
I'm going to have a play now and see if I can implement what I'm talking about.

Sweet abbreviation of the init. Pretty snappy huh!

[geekmaster]

As you can see (and hear), random() as used in this "noisy" demo gives an amplitude modulated "semi-percussive" sound effect, while sin() as used in twobob's "tones" demo gives pure unmodulated sine wave tones.

The question still stands though: If sin() gives sine wave tones, would replacing it with (x*x) give "square wave" tones? (That's a "waveform" joke, folks!)

[geekmaster]

Originally Posted by twobob

HA! Quality.
...
Sweet abbreviation of the init. Pretty snappy huh!

Hopefully, knc1 does not think that my "geekmaster style" condensed code is as "Horrible!" as your parody of my code.

Personally, I think it is much easier to study and understand my sound code shown above (click the "Show" button to see it) than it is to study or understand your "knc1-friendly Astyle" formatted version of your tones demo, with the "Horrible!" amount of vertical scrolling required.

[twobob]

For my part I would like to see it documented to indicate why you used certain values or number types to constrain number ranges.

unsigned char buf[1024]; // play buffer (Matches output blah blah)

That type of information is vital - like -
"chose u-chars for my buffer so the output value of 0 - 255 would exactly match my sample types u8 maximum range." at least in a note somewhere.

"Type equivalences for the 16 bit sample range would be BLAH"

It's these type of implementation details that give a newbie developer insight into making what is "already there" work for better for them. Plus it documents them for everyone. including you.

I am all for the condensed style for demo code - with notes available. or the longer more documented style for walkthroughs. There is a middle ground of course and that is where most of us live.

I am fiddling with swapping in a known length of 0's at a known rate to give perceptual tempo.
Good fun!

[geekmaster]

Originally Posted by twobob

For my part I would like to see it documented to indicate why you used certain values or number types to constrain number ranges.
I did that in a "Theory of Operation" in some of my posts where they "funny business" was what I was trying to teach.

In this case, the "funny number stuff" is just there to synthesize some interesting noise.

If this had been a "musical synthesis" demo, I would have tried to show what was going on in the "magic formulas". This is so simple I did not think that necessary, but because you are "into" music, I will do that now... Done! I added a "Theory of Operation" section for the tiny sound synthesis formula to the Top Post.

Regarding internal documentation, I use a little inline commenting where needed, and I document the important variables that you may want to change with inline comments where they are defined. But stuff that is "just there" to be used and not changed, I like to "black box" so it does not distract from the "important" stuff.

Feel free to create fully comment hybrid-style source code that has more documentation if you want, but I would rather move on to the next incremental step in my evolution of native mode sound software for the eink kindles. I got a lot of professional criticism by colleagues over the years for "too many comments" in my code, so now I try to make my code small, simple, and self-evident, so it only needs minimal comments to guide you through it (with the help of RTFM on the "standard" function call parameters and data structures).

[twobob]

Originally Posted by geekmaster

In this case, the "funny number stuff" is just there to synthesize some interesting noise.

If this had been a "musical synthesis" demo, I would have tried to show what was going on in the "magic formulas". This is so simple I did not think that necessary, but because you are "into" music, I will do that now:

Geekmaster "noisy rhythms" Demo,
Sound Synthesis Algorithm,
Theory of Operation:

Spoiler:

The C "random()" function returns a random positive integer value (including 0). Normally you limit it to a range by truncating it. In this case, the "&3" keeps only the bottom two bits (giving random values in the range 0-3).

The outer "i" loop is repeated 256 times, and each iteration plays a 1024-byte sound buffer after it is filled with "amplitude modulated" random number by an inner "j" loop.

In the inner "j" loop, the buffer gets filled with 1024 2-bit random numbers that have been multiplied by (i*350). This multiplication changes (modulates) the maximum value of the result (i.e. the peak amplitude of the waveform in the buffer). In this case, i*350 causes the max value to be greater than 255 in many cases, so when the value is truncated to 8-bits and stored into a 1-byte sound buffer position, it gets "distorted" in a way that causes some very large numbers to become small (quiet).

Because the amplitude modulator control variable "i" sweeps from 0-255 while this demo plays, each 1024-buffer (short time period of random "hissing" noise) gets its volume set to a different "constrained random" value. I chose different multiplier (distortion/gain) values until I found a value (350) that sounded pleasing with a nice syncopated periodicity, giving it a not-so-annoying semi-percussive rift.

Enough? Or should I continue? I can go into deeper layers of detail on number theory, human perception, software algorithms and optimization, and personal opinion all day long. I think I will quit now. Any questions?

Excellent! I think that covers it nicely sir.

In other news I think I finally managed to x-compile alsa...

[geekmaster]

Originally Posted by twobob

Excellent! I think that covers it nicely sir.

In other news I think I finally managed to x-compile alsa...

While you were typing that, I moved that "Theory" block (intact) to the top post, where it really belongs. It is now "mirrored" in your quote too.

I had to copy the freshly built alsa files into my toolchain directories before I could compile sound apps.

Sadly, WHERE to put the alsa header file varies in various examples. Some use the default /include folder (like I used in the "noisy" demo), and others prefix it with alsa/ inside the #include (like you did in the "tones" demo). Perhaps it would be good to copy that header to BOTH places in the toolchain folders, so both demos can compile as-is...

EDIT: Regarding coding style and documentation: As you can see, it took 1542 characters of comments to precisely describe the operational theory of the "(random()&3)*i*350" logical expression used to stuff values into the sound buffer. Describing my much larger dithering expressions would take MUCH more effort (and words). I think that injecting those comments (and more) into my condensed code may somewhat interfere with how much REAL code fits "above the fold" (i.e. no vertical scrolling). It would also spread related code segments so far apart that relational perception would be severely degraded while "absorbing" the code. Remember, all of the BEST programmers are "trance coders", and need to absorb the structure and nuances of the code IN PARALLEL. Just read some biographies of famous software programmers and you will see what I mean.

For a great little introduction to trance coding, read this: http://www.wintermute.me.uk/writing/coding-trance.html

[twobob]

Originally Posted by geekmaster

While you were typing that, I moved that "Theory" block (intact) to the top post, where it really belongs. It is now "mirrored" in you quote too.

I had to copy the freshly built alsa files into my toolchain directories before I could compile sound apps.

Sadly, WHERE to put the alsa header file varies in various examples. Some use the default /include folder (like I used in the "noisy" demo), and others prefix it with alsa/ inside the #include (like you did in the "tones" demo). Perhaps it would be good to copy that header to BOTH places in the toolchain folders, so both demos can compile as-is...

EDIT: Regarding coding style and documentation: As you can see, it took 1542 characters of comments to precisely describe the operational theory of the "(random()&3)*i*350" logical expression used to stuff values into the sound buffer. Describing my much larger dithering expressions would take MUCH more effort (and words). I think that injecting those comments (and more) into my condensed code may somewhat interfere with how much REAL code fits "above the fold" (i.e. no vertical scrolling). It would also spread related code segments so far apart that relational perception would be severely degraded while "absorbing" the code. Remember, all of the BEST programmers are "trance coders", and need to absorb the structure and nuances of the code IN PARALLEL. Just read some biographies of famous software programmers and you will see what I mean.

For a great little introduction to trance coding, read this: http://www.wintermute.me.uk/writing/coding-trance.html

Yeah I agree. But helpful to have those notes adjacent to the code.

I recall programming a tarot program a zillion moons ago for an x086 series, it was a requirement back then to have a decent structure in your head given the limited resources before you started. Times really haven't changed that much all in.

The notes were helpful. : )

[twobob]

the ALSA folder is a parent-referencing sym link.

Put it in the root and let it sort itself out.

[geekmaster]

Originally Posted by twobob

the ALSA folder is a parent-referencing sym link.

Put it in the root and let it sort itself out.

Ahhh.... That explains why copying extracted kindle GPL source trees on shared ext3, using a windows copy program, often got stuck in an infinite succession of nested /alsa/alsa/alsa/... folders until it got a "path too long" error and aborted.

I did not make that connection until now that I saw your explanation.

Regarding helpful notes, I have often put the "theory of operation" inside the README file for smaller commercial programs (or an operating manual appendix for significant works).

But this is a hobby, so Theory of Operation is done only if the thing being taught depends on it (or on request, as in this case).

[twobob]

Originally Posted by geekmaster

But this is a hobby, so Theory of Operation is done only if the thing being taught depends on it (or on request, as in this case).

Yep, It's just nice to be able to pick up someone - who clearly knows more than you- 's code and be able to illicit some substance from it via some notes.

At the end of the day I would rather you spent more time making awesome things and less time writing notes because from a purely selfish level I would - by proxy and your generous nature - gain access to more awesome things more quickly.

That said, even I was scratching my head why you were bottom trimming the bits and range wrapping the numbers (was it distortion effect? is it an oversight?), in essence breaking the numeric link between range and outputted range makes it tough for someone making the transition from thinking in analogue to digital.

I myself am guilty of such range wrapping (as you may have noted) in the tones demo to get quick and dirty access to "awesome". Just thought I would point out that the link between total available numeric range and the ability to flaunt that constraint to make it do awesome maybe needed pointing out in this instance.

bitwise truncation and range wrapped distortion are not exactly entry-level audio-theory subjects (well, they are actually, but you know what I mean)

Thanks for making it nice and clear. In other news: I have indeed got my plughw etc interfaces back. Happy days.

[twobob]

Hmm. u8? I wonder what I could get that to sound like with movie sound tracks...
*gets out some tools*

46 min of audio:

1152 MB @ 44k 16bit stereo
86.2MB @ 8k 16bit stereo
43.1 MB @ 8K 16 bit mono
Raw is 42.1 on the disk.

I'm going to try to squish it down to @ 8k 8 bit mono.
see what I get - should be two timesless or something.

If I could get that listenable...I'll see if I can get the noise shaping right...
Could be useful

EDIT: Yes. It's 21 MB uncompressed. 12.9 MB in a tar.gz.

so basically 100 times smaller? not bad.

[geekmaster]

For A/V movies, we will probably need more Theory of Operation when we start using pthreads so that one thread can be stuck in the eink update syscall while the other thread is stuck in the sound buffer write library call. And maybe a third thread to run the GUI.

And u8 (unsigned 8-bit) mono audio should be fine for tiny little speakers. The viewer will be distracted by the video anyway. Of course, using quality headphones while watching music videos may be a little dissapointing on both the audio and the video, in which case an eink kindle is clearly the wrong platform.

So yes, u8 audio is quite appropriate for long persistence low framerate eink dithered monochrome video, I think...

And besides, the relatively simple C code public domain cellphone codec I am porting for the gmv mono audio track is only 8-bit.

Of course, 8-bit audio needs an audio compander algorithm (dynamic range compression) to avoid severe distortion on low volume audio passages or clipping (fuzz box) on high volume audio sound effects.