25 comments

[ 2.3 ms ] story [ 62.6 ms ] thread
To the tune of Sound of Silence by Simon & Garfunkel:

    Hello malloc() my old friend,
    I've come for mem'ry once again,
    Because a pointer silently creeping,
    Filled buffer that I was keeping,
    And the signal that I trapped was a bus error.
    Didn't care.
    Because I still... have malloc()

    There were pages that I missed.
    My OS had sent them to disk.
    Try my best to not hit swap,
    Looking for data I could safely drop,
    I compressed some bits that I kept stored in place
    Freed some space.
    But then I still... used malloc().
(comment deleted)
This seems cool, though I don't entirely understand it. "Generates raw WAV output by hooking malloc() and read()." What does that mean exactly?
It uses hooking to intercept calls to malloc() and read(), calls the real functions, generates a square wave whose frequency is based on the size of the operation, dumps the generated sound data to WAV, returns the output of the real function calls.
Heh really cool
Reminds me of when I was a kid, and I had a Tandy CoCo and a tape recorder deck that was the only way to save any programs you wrote on it. I tried playing the data tape a few times.
Yes! I used to have an Amstrad CPC 464 with a tape deck and it would play the tape through its internal speaker as it was loading a program into memory. The amount of time sat around watching screens like this:

https://www.youtube.com/watch?v=OvChkOHgDIo

    void* read( int fd, void * data, size_t count)
    {
      ...
      gen_square_wave( 44100 , CLAMP(count, 20, 20000 ), CLAMP( sizeof(data), 100 , 1700), 0.7 );
I don't get it, isn't sizeof(data) always the same, and usually either 4 or 8?
Since sizeof is a compile-time construct, it's always always the same (in C; in C++ there are templates to consider)
I haven't read the code, but it looks like this is a bug, or at least superfluous
Yeah, the result of the sizeof operator always compiles to a constant. It may vary from system to system and compiler to compiler, but it's written into the executable as a constant.
It's always the same for your compiler. Using sizeof improves the portability of the code. Because sizeof is calculated at compile time it doesn't make the code any less efficient.

We often think about pointers as being 4 bytes but that isn't necessarily the case. How would a 32 bit pointer map to the addressable memory of 64 bit hardware?

I think his point is more about clamping the value than about using sizeof. It indicates the author expected that value to vary, but it doesn't.
Depending on your application I can see where you might still want to clamp the result. However, I think you're right in this case since the clamped range doesn't make much sense here.
It sounds like when I piped /dev/random to a midi device. (Or was it /dev/urandom and TiMidity++?)

It was like demos; I would be stunned at the emergent complexity and compactness, and it would only elicit shrugs from friends.

I'm reminded of some of my favourite C 1-liners for synthesis:

    main(t){
        for(t=0;;t++)
            putchar(t*(((t>>12)|(t>>8))&(63&(t>>4))));
            //putchar(t>>7|t%45)&(t>>8|t%35)&(t>>11|t%20); // try this too!
    }
.. there's a whole world of 1-liners for synthesis out there, and some of them, frankly, are astounding. Sound is such a beautiful way to understand math ..
Very cool, though I'm having trouble getting any audio out trying it myself. I can build & LD_PRELOAD the .so fine, but the pipe to aplay produces jibberish in the terminal without audio.