Takashi Iwai wrote: > swami (formerly smurf)?
I did mean a non-GUI shell command that could be run remotely and/or via a cronjob. My thoughts are to split up that mega-soundfont on a web server and somehow allow updates to individual parts via a web interface so that anyone could keep their own "reference soundfont" copy uptodate via rsync (linux to linux only). Ie: anyone could download that mega-sf2 once, split it up, and keep it uptodate via rsync and/or push individual instrument updates to the server where it's spliced back into the main sf2 tree (somehow) and anyone else only needs to run rsync daily/weekly/monthly and rebuild (compile?) the parts back into a real working soundfont on their local machine without re-downloading the complete sf2. Obviously throwing around a multi-100MB file just because one instrument got updated is just not going to be possible, probably ever. Something like this would greatly assist managing online collaborative audio projects at audio.opensrc.org. MIDI files are easy to transfer and could be a major part of the overall project but also close to useless unless those participating have access to the same instruments. >>Oh, and does anyone know why sfxload has not been ported to a >>100% ALSA interface ? > > my laziness :) No way... you are too busy doing more important things :-) > well, more exact reason is that i don't like the implementation of > soundfont parser on kernel. > in the case of sfxload, most of structure-parsing is done in the > awesfx library. sfxload just transfers the parsed raw data to the > driver. > on the present alsa instrument layer, the (most of) instrument > structure must be parsed on the destination part for keeping > generality. and i believe it's too much for a kernel driver. > > perhaps this can be implemented better as an alsa-lib's shared object > model, accessing the hwdep device on each card. I appreciate your comments but I can only wish I knew WTF you are talking about. I'll try to look at some code to get half a clue. For me personally... sfxload is the ONLY reason I need OSS emulation. Ultra minor point FWIW... my 6 months of lockups on an AMD machine ended with rc2 and when I moved my SBlive card to a different slot. I finally found that card was sharing an IRQ with both my USB subsystem and an eth card so 3 devices sharing an IRQ might have been most of my particular problem (plus being on a VIA mobo w/ nVidia video card). --markc ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Alsa-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-user
