At Tue, 02 Jul 2002 21:19:35 +1000, Mark Constable wrote: > > 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. an interesting idea. once ago, i wrote a utility included in awesfx package to convert between soundfont and text. this is not exactly what you want, but theoretically this kind of tool must be easy once when you have a library to parse the soundfont and rebuild it again.
i think swami includes already a good library to handle such a thing. Josh, how do you think? > 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). yes, sharing three devices with a same irq is already a bit too much. also, this might be also influenced by the boot sequence. for example, i once experienced that a notebook lock up after the initialization of sound driver. this was because usb was not initialized and the connected device triggered unknown interrupts endlessly. Takashi ------------------------------------------------------- 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
