Dissonance DS: The Long WIP Update

The last time we featured Dissonance, the homebrew app from Dave Brady, was back in May. In case you missed it, Dissonance allows you to stream an internet radio station to your DS. After a long break, Dave is back with an update on his killer app. The Dissonance WIP Report is a long one (which means the next Dissonance update will be even better), so happy reading!

Dave begins by saying the DS version of Dissonance requires devkitARM, dswifi, and libnds. But after the release of Dissonance 0.3, he says he’ll probably have his own high level library anyway.

Check out the full details of the Dissonance DS update after the jump!

The last time we featured Dissonance, the homebrew app from Dave Brady, was back in May. In case you missed it, Dissonance allows you to stream an internet radio station to your DS. After a long break, Dave is back with an update on his killer app. The Dissonance WIP Report is a long one (which means the next Dissonance update will be even better), so happy reading!

Dave begins by saying the DS version of Dissonance requires devkitARM, dswifi, and libnds. But after the release of Dissonance 0.3, he says he’ll probably have his own high level library anyway. As for the details of his report here they are:

dissonance.h
This file contains global macros and defines that are relevant throughout the program. It might also contain misc function prototypes that don’t fit in elsewhere.

dissonance.c
This is the main entry point for the program. It has the ARM9 main loop when compiled for the DS, and it is the entry point for the Linux client.

The aim is to have very little actually in this file, as with dissonance.h, as it basically calls functions from the other files to do the actual work. But it’s here where the main logic of the program is working. This includes things such as setting up the playlist, controlling the state machine, and playing the music. It might also include misc functions that don’t fit in elsewhere.

mp3.c/mp3.h
This is where MP3s are decoded.  A stream is passed into the MP3_run function,and it is eventually outputted in PCM WAV format in the prcs_func. Still up in the air, as I am not quite sure how I WANT it to work. Edit before 0.3 release.

network.c/network.h
This is a wrapper for sockets, to make it a little easier to read and write from a network stream. First, you init the network, then you connect to the station you want to connect to, then you can send or receive as you would like. After you are done with the connection, you can close it down, in order to prevent memory leaks.

playlist.c/playlist.h
This is where playlists are parsed.  Standard pls format playlists are used, and must be fed into PLS_read() in a null terminated string.  From there, you can get the number of playlist items, or retrieve the titles or urls of the different stations.

I am considering adding an extension to the PLS format to include sample rate, but I may just bite the bullet, and figure it out with code.

sound.c/sound.h
This is a wrapper for sound functions. There are functions for initializing sound, playing a buffer, or stopping playback, as well as finding the current position of the read pointer (this may not be exact on the DS). Sound channels should be closed when you are finished with them.  SND_shutdown should be called when the program is done with processing sound.  This will
free all the memory on both linux and DS, shutdown the sound service on the DS, and close the connection to the sound server on a linux system.  SND_init should be called if sound is needed again.

input.c/input.h
This is a wrapper for input functionality.  A callback function is registered for each type of event, (SDL keys, or NDS keys, mouse or touchpad), and the callback function is called more or less immediately (immediate on the DS, nearly immediate for Linux) in response.

graphics.c/graphics.h
This is a wrapper for low level drawing functions.  When initializing, 3D or 2D is selected, giving low level functions appropriate for each.  You must also select which window you are initializing.  3D functionality will result in an OpenGL window being created, and 2D will result in an SDL/Tile based window. 

This will probably not be finished in any way, shape, or form before 0.3, as it’s the biggest of the low level wrappers to actually accomplish in terms of coding, testing, and learning.  (I am still not overly proficient with the NDS 2D interface… and have not done much 3D work on the DS yet… and I have not done anything in SDL that’s 2D before either).

gui.c/gui.h
This is where all graphical output should be done.  This includes things such as equalizers, visualizations, controls, or any other such things. Please edit and fix before 0.3 after specs are finalized.

Via Dave Brady