Hi,


> Belive me, initially writing the SDL_soundserver was a royal PITA,
> because I had to abstract out the soundserver core logic from the IPC
> mechanism.  But that's behind us now.  But if there turns out to be more
> places where we should abstract/rewrite, then hell, it's not like
> FreeSCI has never had unstable sound code.  :)

;-)
The new abstractions would encompass pretty much all the code you didn't
touch. Your changes abstracted the initialization/communication part, and
then relied on the main loop to do the actual work. Current suggestions
would split up that main loop into "process_command()" and
"process_sound()", and further abstract (in a second step) the sound
processing.

> (Hmm.  I wonder if I should revive my opl2 soundserver and make it hook
>  into that opl2 emulator -- we really need /dev/fm to pull it off, and
>  that's only OSS/Commercial -- I don't think ALSA has something
>  similar.  The /dev/sequencer approach is a dead end because of.. well,
>  timing issues.  *sigh* )

Sure, go ahead! ATM we don't have a PCM output layer, so you'll have to
rely on the emulator to do the actual output, but, other than that, people
without a MIDI capable card or external synthesizer would certainly
appreciate this!

llap, 
 Christoph


Reply via email to