On Dec 19, 2007 4:49 PM, Steve Strobel <steve.strobel@xxxxxxxxxxxxx> wrote: > Thanks for the reply. I think I understand at least the basics of > how Jack works, and I can see how it would work well in > general. Unfortunately, I am working on an embedded Blackfin system > running uClinux and I don't find any evidence that Jack has been > ported to that platform. Also, all of the (simple command-line) > utilities that I hoped to use like aplay/record, mp3play, etc. are > set up for ALSA; I suppose there might be Jack equivalents or a way > of using an adapter of some sort. That sounds rather involved, and > defeats at least some of the advantages of native Jack apps. > > Would it be a reasonable design to make small executables to do jobs > similar to dmix/dsnoop/dshare that do their I/O on named pipes > (fifos), then run aplay/arecord... on those pipes? Once you do this you'll have re-implemented 90% of JACK. JACK should work on your platform - it uses the same POSIX APIs (shared memory and FIFOs) as ALSA to mix and route audio. Actually dmix/dsnoop/dshare have more requirements (SysV IPC). You should at least try it. There are JACKified equivalents to all the apps you mention. aplay and arecord aren't designed for everyday use anyway; they're really just for demonstrating ALSA features and testing drivers. An added bonus is that you'll be using a system that's already been proven in the field, with VERY demanding professional audio apps, on everything from embedded systems to top of the line workstations. Trust me, I've done Linux audio development for embedded systems, and once you go JACK you'll never go back ;-) Lee _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
