Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


Recommended Posts

This question is for any Linux programmers, who may have happened to played MIDI through ALSA.

This is not for the main SDL port, but for the Linux port, which does not use SDL (for those users who do not have SDL).

It was supposed to be a simple effort to change the MIDI sound from OSS to using ALSA, but ALSA documentation is so bad that it is just experimentation.


Currently, I have it playing most of the time.

Randomly, something resets the MIDI tick timer to 0.  This causes the MIDI playing to stop until the tick time catches up to the MIDI stream position again.

This could be due to using the wrong method to set the tick timer to zero, and it is just sitting in the queue, waiting for a random time to execute.  Like, I said, raw experimentation.


Could really use a method to detect when the ALSA MIDI kernel queue is empty.  Not the one that you build MIDI messages into, but the one that it drains into.

I need to detect when it is done, so it safe to change queue settings, and start another MIDI song.

Been through the documentation so many times already and nothing there seems to detect that.  Although I can read the current MIDI tick time.  Been using that for now.



Share this post

Link to post

I am only going to share this, for the amusement of any programmers out there.  It is about how much trouble a little "Hack" can cause.


The Linux X11 port of DoomLegacy was getting the sound worked over, because it was still using OSS sound  interface, and my Linux distribution does not enable that by default.

I decided it was time to update it to ALSA, and perhaps a few other sound drivers.

The sound effects sound had already had a similar selection feature for some time, allowing selection between OSS, ALSA, ESD, PULSEAUDIO. and JACK.

If multiple sound drivers are specified at compile-time, it will generate a menu entry for selecting between the devices for playing sounds.


I did not want the sound devices to suddenly be switching on and off when the user was scrolling through the menu selections.  I implemented a "Hack" where

a sound config variable change would send an invalid value to the sound player, to tun it off.  After a delay, it would send the code for the new device to the sound player.

While the user was scrolling through the menu selections, the delay would keep being reset, so only the final value would get sent to the sound player.  This would implement a nice clean mute while the user was flipping though sound device selections.


This was implemented in the sound system, which was a mistake.


It worked fine, so when it came time to work on the music player, it got the same mechanism.

It got a menu for selecting between multiple music playing devices.


ALSA is not well documented, so it is a matter of experimentation as to what each of the many library calls actually does.  I got instrumentation all over the place.  One thing I am watching is the the current music tick, and the ALSA queue tick.  These are the music "time", where it is in the music playback.

I had got into looking at the queue tick in an effort to throttle the playback, so to not saturate the ALSA queue, and to make it more responsive to DoomLegacy changes.

The responsiveness problem is likely to go away, as other ways to deal with that are being worked.


During testing, the music would start playing and then suddenly stop, and then start playing again.

The instrumentation on the ALSA queue showed that the ALSA queue tick time was being reset to 0.   When that happened, all the MIDI notes in the ALSA queue would just stay there until the ALSA queue timer had got back to the time when they were scheduled to be played.   There would be silence while the timer slowly worked its way back to where it was, and then it would pick up playing where it left off.


Now, I got ALSA experimental hacks all over the code, trying to figure out how to use it without proper function documentation.  I am testing everything that looks suspicious.  To shorten this narrative a little, it was not the ALSA code, it was that "Hack".


In DoomLegacy, the config variables have an extensive system for the user to change them, and for their values to be saved in a config file.

At startup the config variables get set, and then the sound system is initialized.  The initialization of the sound player had been carefully crafted to deal with the config file loading.

A second setting of the sound config variables was expected, and it was arranged for this to properly setup the sound player.


The "Hack" was catching the change to the sound config (from loading the config file).

It then issued an "off" selection, that got overridden by the initialization of the sound player.

The sound player would startup, initialized itself, got the intro music song, and would be playing.

The delayed sound device setup call from the "Hack" would then occur.


The sound device change code of the player was one place that was not instrumented, because problems were not occurring there.

The one thing it did that was noticed was to initialize the ALSA queue, which set its timer to 0.   The rest is just details.


The mechanism for putting a "MUTE" duing menu flipping has been moved out of the sound system, into the menu system, where it no longer gets triggered by config file loading.

The music playing using ALSA is much better now.   A little tuning of that responsiveness has to be done, like taking out half of that code as unnecessary.


If you read this far, then Thank You.





Edited by wesleyjohnson

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now