Audio (video) - Kindle. Getting it up and running, Code level.

[twobob]

Originally Posted by geekmaster

No need for static, now that it works both ways on all my kindles (that have sound support).

When you get the audio buffer to stop glitching, I want to see the source code. The place to interleave audio into a gmv file is in the raw2gmv program.

I have enough working now that I can build your tones program, after building and adding alsa lib (dynamic and static) to my cross-tools. Next step is to mod tones to do something "less annoying" (and add in some video demo code too).

BTW, it took me a bit to realize that I had to hit the power button on my DX before the Vol- button would work, when tones was playing TOO DAMN LOUD!

This gives us another reason to get USB host mode working, so we can stick a $3 USB sound stick on a K4 to give it sound support too (just like the XDA folks did for the Nook Simple Touch). Adding a USB keyboard to a K4 would not be too shabby either.

I'm still in the - JERKING LIKE CRAZY - stage right now

I could probably manage the buffer more sensibly but I'm seeing if I can just shoehorn something together in the short term.

It was a real warm feeling wandering around with my newly converted movies running sound. That said, I still think the audio format needs looking at.

Wav @ 16k - 20k produces files that are as large as the movie info
So assuming we have a microbe of performance left later on some IP free compression might not go amiss in the mix.

It's a learning curve for me right now on the Alsa implementation but I'm giving it my best shot. Far too much (prepare_buffer) this and (snd_pcm_avail_update(handle)) that, for my liking, I'm more a scrunching up numbers to make sounds man myself.

But slowly slowly catchee monkee, I suspect if you put your mind to it you could implement it first. In the absence of that I shall rumble on

[geekmaster]

Originally Posted by twobob

I'm still in the - JERKING LIKE CRAZY - stage right now

Umm... Shouldn't there be an OFF in that sentence?

Originally Posted by twobob

Wav @ 16k - 20k produces files that are as large as the movie info
So assuming we have a microbe of performance left later on some IP free compression might not go amiss in the mix.

The K3 performance drain is in the eink "wait loop" inside the syscall, so not a lot we can do about that unless we find an "async" way to do eink updates like on the K4/K5 (where you do your own delay loop with sensible sleep() calls inside them).

Originally Posted by twobob

It's a learning curve for me right now on the Alsa implementation but I'm giving it my best shot. Far too much (prepare_buffer) this and (snd_pcm_avail_update(handle)) that, for my liking, I'm more a scrunching up numbers to make sounds man myself.

Yes, I want to do sound stuff, and I also prefer the "listening to twisted numbers" stuff much more than the buffer pushing. But I really crave "as SIMPLE as humanly possible". I get my fun REMOVING every parameter and every line of code that I can without killing the code. Hobby coding after all. The sound stuff just isn't there yet. I will have to see just how minimal I can make it and still keep it working on all the kindle eink models.

Originally Posted by twobob

But slowly slowly catchee monkee, I suspect if you put your mind to it you could implement it first. In the absence of that I shall rumble on

Unfortunately, I adapted to the timezone shift the wrong direction, needing 18hrs of sleep for several days. I have weaned it down to 12, and now 9. I used to get by on 2-4 hours per day. I hope this is not permanent.

[twobob]

Originally Posted by geekmaster

.....The K3 performance drain is in the eink "wait loop" inside the syscall, so not a lot we can do about that unless we find an "async" way to do eink updates like on the K4/K5 (where you do your own delay loop with sensible sleep() calls inside them)....


...I get my fun REMOVING every parameter and every line of code that I can without killing the code. Hobby coding after all. The sound stuff just isn't there yet. I will have to see just how minimal I can make it and still keep it working on all the kindle eink models.

Yes, but actually the issue is in the sound stuff, I'm basically managing the buffer incorrectly, just need to figure out what exactly I can push in and when. The video plays okay.

my current toying around is NOT a complete solution. an interleaved format to allow for slip estimation is required. All I'm doing is preloading the wave and then slipping it through to the pcm amidst the video noise at the appropriate time...
Kids stuff really while I get my hand in at ALSA developing.

I don't think that final solution will be too ugly TBH. There appear to be several shortcuts in initialising a card. I can maybe get it down to 6 or 7 lines with some scroobius wanglage. Have to see.

[geekmaster]

Originally Posted by twobob

I don't think that final solution will be too ugly TBH. There appear to be several shortcuts in initialising a card. I can maybe get it down to 6 or 7 lines with some scroobius wanglage. Have to see.

Looking forward to that 6 or 7 lines of code!

[twobob]

Originally Posted by geekmaster

Looking forward to that 6 or 7 lines of code!

(They might be long lines )

[geekmaster]

Originally Posted by twobob

(They might be long lines )

It helps to use two-letter variable names, and remove all unnecessary whitespace, and use complex logical expressions instead of conditional branches (just look at my code).

The logical expressions actually run a LOT faster on modern processors -- just look at the "Aggregate Magic Algorithms" for examples: http://aggregate.org/MAGIC/

It also helps to keep your sonic screwdriver handy:

[twobob]

Originally Posted by geekmaster

Looking forward to that 6 or 7 lines of code!

See Updated Code below for easier reading

Okay I better go actually run this to check it works. hehehe.

EDIT: Checked - it works

[geekmaster]

You do not need error handling to tell you that you are stupid. It is not mission-critical or life-critical code after all. If it does not work, go RTFM, and fix it.

The code posted above is less likely to send the reader away screaming in horror.

EDIT: Actually, I do START with error handling code (until I get it working), then I strip that out of the working parts that no longer need it. By the time I publish it, any residual error handling code is only there as a fallback to workaround hardware for firmware issues.

EDIT2: Of course, in my PROFESSIONAL code, in some places there is much more "error handling" than algorithm. And when deviating from "standard methodology", I include a rationale commentary for why that deviation was needed and what are the consequences of altering it. I also include embedded references throughout my code showing WHERE I got my ideas, to prove that they are unencumbered by patents or viral licensing. But I still minimize white space though (maximum "above the fold" content for readers who rarely use scrollbars or cursor keys).

EDIT3: Now that K5 sound works, it is time for the "Touchscreen Stylophone" I mentioned earlier.

[twobob]

This is a reinterpretation of the demo here:
http://equalarea.com/paul/alsa-audio.html#playex

There is a useful overview of the PCM interface that is a bit scary but not a terrible read here http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html

EDIT: Here is the Astlye compliant version of the code with additional notes and highlighting of important areas:
(In the preferred style of Knc1)

Spoiler:

#include <alsa/asoundlib.h>

main (int argc, char *argv[])
{

    // The err value being setup here would ordinarily 
    //  be populated by error handling code that is "wrapped around" 
    //  each of the calls  to the alsa methods (in bold). 

    //  I have left in one example of this construct on the snd_pcm_writei
    //  method to show how this works in practice. (At the end.)
    //  This repetitive construct is elided here for brevity, further examples
    //  can be found on previous posts on this thread
 
    // i = index for looping over buffer at the end - It's a superfluous 
    // variable used only to illustrate buffer iteration and can be ignored

    // err = alsa method return codes / frame counts etc...
    int i, err;

    // buf = An example data store to splat into buffer at the end
    // You would fill a similar construct with something 
    // useful in the real world.
    short buf[128];
 
    // Declare an instance (or occurence if you prefer)
    // of the special "Type" defined by Alsa 
    // This tells Alsa the card is an available sound device
    // We use this name to reference the device in other calls

    snd_pcm_t *playback_handle;

    // Similarly we create a new "parameters" construct
    // Simply creating the reference here is enough to create it
    // You can use this to setup the card to your liking
    // We do the bare minimum here to get us going
    snd_pcm_hw_params_t *hw_params

    // This is the 1st Alsa method we have called (directly anyway)
    // note we reference the card via it's handle we just created

    // Then we grab the first argument passed to the command line
    // argv[1] gives us this value - an e.g is below. 
    // (like ./TestProgram hw:0 would return hw:0)

    // At this stage we link the handle to the device hw:0 in this case 
    // (Further details of how devices are configed via conf files in earlier posts)

    // We would get back an error code (into the err construct) at this 
    // stage if something was amiss in accessing the card (bad conf for e.g.)

   // The full details of the enum SND_PCM_STREAM_ETC... can be
   // viewed here the complete PCM command set here

    snd_pcm_open (&playback_handle, argv[1], SND_PCM_STREAM_PLAYBACK, 0);

    // This defines some space for our params constuct
    // c is fussy about memory handling
    // Make some space - remember to tidy it up after
    // Malloc = Think "Memory Allocate"
    snd_pcm_hw_params_malloc (&hw_params);

    // This is defined in the ALSA Hardware section here
    // Fill our params space with a full configuration construct for a PCM. 
    // Making use of the space we just made and created a skeleton for us
    // Note we still reference the card via the handle from now on in
     snd_pcm_hw_params_any (playback_handle, hw_params);

    //  Restrict a configuration space to contain only one access type.   
    // The full reference for the method is here
    // I seemed to need to set this to just one type to get the card going.

    // Perhaps setting one val is absolute minimum for configuration
    // I am unsure but this got it working for me without going on to set 
    // the sample rate, access format etc. the full gory details are in the 
    // original demo, this is about getting the kindle going with minimum code

    // the full tech ref for the enum SND_PCM_ACCESS_BLAH is here
    // In essence it is pcm_read/write interleaved access 

    // Pcm means it's not done in memory it's (kinda) direct to card

    // read/write means duplexing possible, Interleaving means that we 
    // alternate samples for the left and right channel (LR,LR,LR...).

    // It's a very generic choice. You could "refine" this decision to your needs
    snd_pcm_hw_params_set_access (playback_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED);

    // The next utility method puts our params decisions in motion 
    // "Install one PCM hardware configuration chosen from a configuration 
    // space and snd_pcm_prepare  it." say the docs here
    // so as you can see this runs another method internally for us. Happy days.
    snd_pcm_hw_params (playback_handle, hw_params);

    // This simply tidies up the memory space from the param construct 
    // as we are done with it, 

    // it's always good practice in c to destruct your disused objects. 
    snd_pcm_hw_params_free (hw_params);

    // Showtime, as shown here this "Prepare[s] PCM for use." 
    // All of these methods could have been wrapped in error handlers, 
    // only some of them have real value though, this is maybe one of them 
    snd_pcm_prepare (playback_handle);

    // We are now ready to so some stuff so let's write some interleaved data.
    // Everything after this point is "Program", we have done our job really.

    // buf is just some 0 data 128 long, 
    // 128 is length of buf, effectively buf.length
    // 10 is just a value to show looping - has no instrinsic meaning
    // write 10 * 128 shorties via the handle using interleaved writing

     // This says - in English-Psuedo-Code
     // Try to write 128 shorts to the PCM
     // If it fails a) return an error value for the process and Then 
     // b) exit the application with a code indicating Failure 
     // Do this ten times 

    for (i = 0; i < 10; ++i)
    {   if ((err = snd_pcm_writei (playback_handle, buf, 128)) != 128) {
            fprintf (stderr, "write to audio interface failed (%s)\n",snd_strerror (err));
            exit (1);
        }
    }

    //Tidy up. Ref here 
    snd_pcm_close (playback_handle);

    // Exit the application with a code indicating Success. 
    exit (0);
}

The Original thrust of the thread continues below.

Originally Posted by geekmaster

I also include embedded references throughout my code showing WHERE I got my ideas, to prove that they are unencumbered by patents or viral licensing. [/COLOR]

This init code is simply boiled out of an Alsa init code example, 7-ish lines (as demoed below) and you are ready to play, not bad considering the hellatiously verbose constructs of alsa.

Here is the completed basic init code: (In GM's preferred compressed style)

Spoiler:

#include <alsa/asoundlib.h>

main (int argc, char *argv[])	{

//INIT BLOCK
int err; short buf[128]; snd_pcm_t *playback_handle; 	
snd_pcm_hw_params_t *hw_params; 
snd_pcm_open (&playback_handle, argv[1], SND_PCM_STREAM_PLAYBACK, 0);
snd_pcm_hw_params_malloc (&hw_params);
snd_pcm_hw_params_any (playback_handle, hw_params);
snd_pcm_hw_params_set_access (playback_handle, hw_params, 
SND_PCM_ACCESS_RW_INTERLEAVED);
snd_pcm_hw_params (playback_handle, hw_params);
snd_pcm_hw_params_free (hw_params);
snd_pcm_prepare (playback_handle);
// Write something
snd_pcm_writei (playback_handle, buf, 128) ;
//Tidy up.
snd_pcm_close (playback_handle); 		exit (0);}
//Done.

The 'buf' is just to demonstrate something being pushed PCMwards. Obviously it's not required. Hacked and slashed demos. That's the best I can do with my current knowledge. See what tomorrow brings perhaps there is a quicker way. But I doubt it.

(I'll go fix the code in the post above, just in case someone tries it)

[PoP]

Originally Posted by geekmaster

I have alsa lib 1.0.25 (the latest) working on K3 and K5, with static linking (and now dynamic linking too).

[Gory details from post #132 omitted]

EDIT2: It works on my DX (white) as well. Testing it on my K4s will be a bit harder, I'm afraid. (

GM, you will be please to know that your dynamically linked tones works on the Raspberry Pi (debian wheezy) too!

[geekmaster]

Originally Posted by PoP

GM, you will be please to know that your dynamically linked tones works on the Raspberry Pi (debian wheezy) too!

AWESOME. Now if only my eink code worked on the RasPi... Need to "fix" that, I suppose (when I add Nook Simple Touch support, as planned)...

It is actually "twobob's tones". All I did is figure out how to build it so it works on more kindle (and non-kindle!) models.

[twobob]

Originally Posted by geekmaster

It helps to use two-letter variable names, and remove all unnecessary whitespace, and use complex logical expressions instead of conditional branches (just look at my code).

The logical expressions actually run a LOT faster on modern processors -- just look at the "Aggregate Magic Algorithms" for examples: http://aggregate.org/MAGIC/

It also helps to keep your sonic screwdriver handy:

Yeah, I already looked at the magic stuff. will be handy when i am trying to do something clever. init-ing alsa hardly requires the swiss army knife of maths no amount of clever crap (aside from just downright mapping some ASM, stored executions or some other ridiculous overkill) is going to make alsa any more efficient.

I have two sonic screwdrivers in my house. the beauty of kids. ( and a sonic lipstick might I add) although none of mine have IR skills. meh.

I will be happy to simply have the init code running with your vid and some striped audio - THEN I will break out the time domain mythamatics. Till then? like opening a can with a jackhammer.

[knc1]

Originally Posted by twobob

This NOW TESTED init code is simply boiled out of Alsa init code example.

Looks straight out of the GM Style Manual. (Horrible)
Yes reader, you read that correctly, that is a criticism.

- - - -

Allow me a few words in support of my opinion to any one posting example code at this site - -

* Consider the audience here;
With a few dozen exceptions, the readership here has little technical knowledge and little or no programming experience.

* Consider the image you project;
Does not all of those hours, over all of those years, learning the art and science of programming, deserve a better representation?

* Consider the society that gathers around a hobbyist forum;
Members of a society, even an electronic society, form a community of like-wise behaving members.
So like it or not, publishing here puts a person in the role of "Leadership by Example".
Does not the time and effort that goes into solving a problem and presenting a solution earn itself a more professional example?

* If personal considerations require an extremely compact representation of program code, is that any excuse for not running the result of your hours of long, hard, work through any one of many source formatting routines before publication?
Let the glory of your solution shine in comprehensible code. Do not publish for bragging rights to how much whitespace you can eliminate or how many statements you can squeeze on a line.
Publish in a style that you can be proud of, for others to see how much pride you take in your own efforts.

* There are specialized sites for this style of programming, such as: http://www.ioccc.org/
and their list of winners (with the *.c files posted): http://www.ioccc.org/winners.html
go post your obfuscated code on their site.

[geekmaster]

Originally Posted by knc1

Looks straight out of the GM Style Manual. (Horrible)
Yes reader, you read that correctly, that is a criticism.

Another criticism from you? Meh...

So run it through AStyle then...

I grew up programming in MACHINE LANGUAGE, with front panel switches and neon lights. We did not need to wait a day for the keypunch ladys to punch our cards (or wait for them to go home so we could punch our own cards).

Although my code is condensed, it is NOT obfuscated. I write it for myself, and I need to see as much code as I can to absorb its patterns without cumbersome scrolling. Mousing breaks the coding trance.

For clients, I just feed it through AStyle to reformat it to their choice of style before delivery.

I can post counterexamples of what I consider to be the most valuable code from others, and it is also coded in a very condensed style. I am not alone. You are welcome to your own opinions, and I am welcome to mine.

EDIT: As I pointed out before, there is a HUGE readership that only reads "above the fold" content. I do the same for web page layout. Fit all the important stuff "above the fold". You can write fluffy popcorn code all you want, and I will write solid condensed code all I want.

And just why should I run MY code through a source code formatter for you, when I do not know which of dozens of popular formats will make you happy (if any)? You can do that yourself.

Have you even EXPERIENCED a coding trance?

Now, which of YOUR personal pieces of self-written code would you like to show us as representative of YOUR "vastly superior" coding style?

[twobob]

Originally Posted by knc1

Looks straight out of the GM Style Manual. (Horrible)

Publish in a style that you can be proud of, for others to see how much pride you take in your own efforts.

go post your obfuscated code on their site.

Hi, This is published in the style of GM. it isn't a final working example it's a whitespace condensed version of the basic alsa code.

As for obfuscated. I swear that is an un-obfuscated as using alsa gets.

I was simply aiming to demonstrate that GM could - in his style - incorporate ALSA code in circa 10 lines. (init in about 7.)

After the last few pages smeared in reference to what these values refer to - and lets face it "snd_pcm_hw_params_any (playback_handle, hw_params);" is pretty bloody obscure - I would hope there is enough x-ref to make sense of these lines.

In the end this does not serve as a fantastically beautiful demonstration of the perfect alsa init sequence. It did meet the needs of it's purpose though.

My apologies if posting the code here offended you in some way?
I'll take that under advisement.