sdl_mixer has the worst midi possible! Any patches for alsa hardware midi access?
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
sdl_mixer has the worst midi possible! Any patches for alsa hardware midi access?
Wondering how sdl_mixer has gotten away with such bad midi rendering for so many years. Does anyone know of a patch or anything to make sdl_mixer use an alsa hardware midi port, instead of the really awful and old timidity backend built into sdl_mixer? It's been years and it's never been fixed. They even added the fluidsynth soundfont backend for soundfont support and even that has similar problems!
I remember that link from a little while back. It doesn't make sense that fluidsynth soundfont support was officially added recently with messed up midi rendering; I have the same soundfont in that article and have confirmed it sounds broken with sdl_mixer-1.2.12 using the built-in fluidsynth backend. Timidity++ renders the soundfont appropriately however, and it provides so much more with reverb control, very high quality resampling (gauss), and it even emulates a lot of midi modules on top of other powerful features; not only that but it supports gravis ultrasound patches appropriately (many high quality patch sets are broken and/or distorted through sdl_mixer's built-in timidity which is based on a really basic and old version) and it can also use compressed patch sets (actually, compressed pat sets isn't confirmed and might not be true).
Only problem is sdl_mixer doesn't call timidity++ server if it's installed and/or running. Sdl_mixer only looks for /dev/sequencer if native midi support is compiled in (don't know how that is with the recent version since they removed the gpl native midi code which differs from the basic native midi code they still have); and timidity++ doesn't support /dev/sequencer when running as an alsa sequencer daemon.
Made a great find and came across this code recently which creates a pseudo /dev/sequencer for timidity++! It's for version 2.0.1 which is a bit dated but if someone can help, I'm sure this would fix all the problems the majority of sdl_mixer programs have with midi. Programs look for native midi at /dev/sequencer which doesn't work on alsa with oss emulation so they revert to sdl_mixer's built in timidity which is really dated, limited and broken (pat sets aren't rendered right). Here is the "timidity-io.c" file by Masanao Izumo:
SDL_Mixer has gotten away with poor everything, not just Midi. Meager audio resampling, finding out which replay freq. is eventually REALLY being used is impossible, so you can't even resample manually before using samples with different freqs etc. etc... buried that thing pretty quickly as "unfit" after a bit testing, then moved to OpenAL. I actually don't know about OpenAL and MIDI, though, but for other things audio, OpenAL is it.
SDL_Mixer has gotten away with poor everything, not just Midi. Meager audio resampling, finding out which replay freq. is eventually REALLY being used is impossible, so you can't even resample manually before using samples with different freqs etc. etc... buried that thing pretty quickly as "unfit" after a bit testing, then moved to OpenAL. I actually don't know about OpenAL and MIDI, though, but for other things audio, OpenAL is it.
Is this still true for the SDL2 release candidate?
Is this still true for the SDL2 release candidate?
I frankly got no idea as i wrote myself an OpenAL-based sound/music player (not using anything MIDI though), which does everything i want and that's that. I got my audio framework (which even supports 3D audio for games, with doppler effects and all that fancy stuff, is super-fast, well designed & programmed and highly portable) and i probably won't touch SDL ever again. As for games, i'd certainly use SFML rather than SDL, so i simply got absolutely no use for SDL anyhow..
Edit: there's a MIDI interface for SFML on <http://www.zorexxlkl.com/sfmidi/>, so if - by any chance - you happen to develop a game, that one might be for you. Of course SFML's standard audio interface is otherwise based on OpenAL.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.