> Linux audio does seem to be a can of worms The worms are still wriggling....
To recap, I had very high processor load from the second fldigi when running two instances of fldigi using PortAudio. The high-load instance was using a USB audio card. That problem appears to be fixed by using OSS instead of portaudio. This is with Xubuntu V9.10, which does not include pulseaudio and uses Xfce instead of Gnome. Now read on: After using the dual-fldigi setup for a while without problems, including a reboot to make sure everything initialised properly, the CPU load hit maximum, with top showing zero idle and the culprit being the fldigi instance using the *internal* sound card. Although the symptom is high CPU load like before, this appears to be a different problem: the misbehaving fldigi was the one using the internal sound card, and the CPU load wasn't just high, it was maximum (corresponding to an fldigi CPU load around 80-85%). If I killed the well-behaved fldigi instance, the load of the misbehaving one just increased to maximum. If I restarted the well-behaved fldigi it worked, BUT while it was running the misbehaving fldigi got no audio - the waterfall disappeared. Kill the well-behaved fldigi and the waterfall reappeared. Eventually I discovered that this is more likely to happen when the PC is rebooted with the USB sound card installed - I haven't yet seen it when the USB device is plugged in after a reboot, which is why this wasn't noticed earlier. The Solution: This was with both fldigi instances having "manage mixer" ticked. The above problem goes away completely if neither fldigi instance touches the mixer. The problem is linked to fldigi's state on startup: If "manage mixer" is enabled in the preferences file the CPU load hits the roof *and stays there* for the session even if "manage mixer" is then disabled. If it's disabled on startup, fldigi behaves itself for that session even if "manage mixer" is enabled during the session. This is 100% repeatable. So the fix is to disable mixer control: since doing that I have had no problems whatsoever. My workaround, which I actually prefer to fiddling with a continuous mixer control, is to create a few macros to select different power levels. They look like: <EXEC>alsactl -f ~/fldigi/icom706-10W.alsa restore</EXEC> Where the files *.alsa are generated by adjusting the mixer values with alsamixer for the right levels and then saving with alsactl -f <filename> store (Is it worth adding similar functionality within fldigi? A row of macro buttons which instantly select previously calibrated power levels is quite useful.) _______________________________________________ fldigi-alpha mailing list [email protected] https://lists.berlios.de/mailman/listinfo/fldigi-alpha
