On Wed, March 20, 2013 10:12 am, Bill Turner, WB4ALM wrote: > Len, thank you very much for the quick review / definition... > > If Jack is a "one card" solution, then it will not meet my needs - and > in fact, none of the applications I wish to use know anything about Jack. > > As a retiree, now on a fixed income budget, I doubt that I could afford > a multi-channel audio card. If, however, you would like to mention a > name or two, it would be appreciated. If your applications don't understand jack, then making it work is probably not something you want to do. There are a number of tutorials around for bridging one app to jack with a fake alsa device, and alsa is able to separate an audio card into separate fake audio devices as well. It would take some fiddling though and probably trial and error. You would still have the problem with default audio being looked for. I do not know if it is possible to export a default audio device to the environment in a script to start your apps or not. The devices I can think of off the top of my head (known to work well with Linux) are the ice1712 based devices such as the m-audio 1010(LT) with 8 i/o plus spdif i/o for PCI slot use or the PreSonus - AudioBox 1818VSL for USB (same i/o as it happens) You are more likely to find the 1010 used for sale as the 1818VSL is quite new. The 1818 can be expanded to 18 i/o but the expansion costs as much as the original box which is already $500. (as you guessed not cheap) I am not familiar with any PCIe cards, so I can't comment. > At this point in time, the majority of the applications are, in effect, > software modems. Ya, I figured that. > With one major exception, most of the applications that I use, do not > provide any choices as to selection of the sound card. The majority > assume that they have exclusive use of the system default sound card. Pulse seems to grab anything connecting to an alsa port it owns. While it is designed for mixing everything together, it is possible to route separate streams to separate sinks. However the tools that are around (pavucontrol and perhaps some CLI tools) require that the ports already be created before changing the routing. That is, the program receiving a signal starts, it may or not make a pulse port at this time. audacity (a recording program) does not actually connect to the port until you hit record or play, for example. So you set your modem program up and hit connect, it connects to the default device via pulse. Now, you can, with pavucontrol, change what device the inputs and outputs are routed to. You would have to do this each time the application was started. Could this be automated? I think so. If the modem program is started from a script (and it could be), then the script would start the program in background and then do a cycle of asking pulse (using DBUS commands or pactl commands) what ports are open. When it sees it's own ports show up it could then use the same tools to reconnect them where they should be. Sort of a crude session management (there are better session management tools for jack). This assumes that once the ports are opened they stay open till the application closes. > FLDIGI is a major exception to this. It allows configuration for the use > of (1) OSS, (2) PortAudio, (3) PulseAudio, and if you are using OSS or > PortAudio then you have control over the Linux device name, or the sound > card name and the ports that you wish to use. If you are using > PulseAudio, then you can specify the name of a remote server. PortAudio will also connect to Jack, however, it does not name it's ports in any useful way. That is they are all portaudio with a number. The number is not static, so if an app opens a portaudio device, closes and then reopens it the port name changes (Yuck!). This makes automated connections hard. I think if you start your system and applications up all in the same order they may be the same. > My initial tests indicated that PulseAudio was intended to mix whatever > sources were not "muted" into a single "output", which then caused > system sounds, etc to appear in the audio stream being sent to my > primary speakers and the application being run. This is why I asked my > original question the way that I did -- and your response seems to > confirm that PulseAudio is a single "studio" control and not a "Master > Control" for a bunch of different studios. It can as I stated above, do individual routing, but it is manual. Pavucontrol is quite versatile, though these kinds of things are not obvious at first glance. > > As a result, I have told PulseAudio "hands off" for two of my audio > cards, and I use the PortAudio feature of FLDIGI on two separate > instances to allow each instance to control a separate sound card (which > in turn are connected to two different radios). That will work. > My fear is that "PortAudio" might cease to exist (or be supported by the > application or the Operating System) and then I would be out on a limb > with no place to go. Portaudio as a library is likely to be around for a while. It is useful to programmers wanting to make things cross-platform as it works in windows as well. I have heard no rumors of it vanishing. audacity uses it and is probably the most used audio program on any O/S platform. But learning new stuff is always good. > So I believe that I need a program or group of programs that can handle > multiple audio cards. Some of these cards will be connected via USB, so > IRQ conflicts should not be a major issue.The majority of the audio > being processed will generally be between 300 and 3000 Hz. USB cards in general have irq issues, something as simple as a USB mouse on the same irq can cause audio drop outs. I have a USB card. I found I had to try it in each USB plug till I found one that worked in a stable manner. (with it's own unshared irq) This was just a USB1.1 audio device at 2 channels 16bit/48k, not anything fancy. > One of my internal cards is a PCI "sound blaster" card, because a few > special purpose programs that I have make use of some of the on-board > hardware features of that card. If it is a SB Live! run it as 48k sample rate, they have issues with anything else. The earlier (and maybe later) cards are ok. > Since the programs that use the SB card are also used in two-way radio > communications, absolutely NO unauthorised or unexpected audio can be > inserted into an outbound signal, such as system sounds, music, etc. Don't make it default then. > Having something like PulseAudio control the SB card is feasible, as it > is unlikely that PulseAudio would try to connect to ALL of the on-board > SB card features. (Feasible, that is, as long as PulseAudio did not try > to mix the audio with other audio streams before presenting it to the > application.) Ok, have you tried this? I would have thought the app would need direct manipulation of the card to do that. BTW pulseaudio does reset some controls at port connect time, such as levels. (at least it does with my HDA internal IF though not my ice1712) I think the card profile can be adjusted though. > Some programs that I use, such as QSSTV, only allow audio to and from > the default audio card. No other options are provided by the author. > I would assume it uses OSS or ALSA, since the author makes no mention > about it. Default card? or hw:0 or /dev/dsp? It is possible in alsa for the default card to be hw:2 for example. I am not so sure about OSS :) > Ideally, I'd love to have something like PulseAudio control all of the > sound cards, and then provide addressable in/out ports (or channels), > that could then be independently connected to the appropriate > applications. It would also be VERY nice, if channel inputs and outputs > could be dynamically configured. They can. I do not know if a pulseaudio source can be connected to two sinks at the same time though. (jack can) > It doesn't really matter that current GUI's don't make independent > control easy or not - and assuming that PulseAudio uses a config file, > as I could then create a script or two to reconfigure PulseAudio on an > as-needed basis. This is assuming, of course, that there is documention > available. I am a retired programmer, so I could learn "C" if necessary. A lot could be done just with shell scripts. Independent control is not hard, just not obvious. Once you figure it out, you may feel no need to create something new. -- Len Ovens www.OvenWerks.net
