Keep audio devices open all the time, and from start of program

[pe1chl]

We are now working on the streaming audio via svxlink, Alsa loopback device and darkice.
It appears to be working now, will do some more testing and tweaking and hopefully some doc.

What caused some problems is the fact that svxlink closes the audio device every time it turns
off the transmitter. It causes issues with the startup sequence of svxlink, darkice and the
parameters of the Loopback interface.

I have been able to overcome them but it requires a mod to darkice. It would work without problem
when svxlink would have the option to keep the output device (in this case a second local transmitter
with output to alsa:hw:Loopback,0,0) open from the startup of the program until closedown.
(instead of only from beginning to end of transmission)

Apparently it was done to work with cards that can only do half-duplex. If possible, detect this
situation during startup (e.g. open the soundcard for receive and transmit and only close the card
for every tx swich when this fails). When it is not possible, please add a config flag that forces
svxlink to keep the card open. Consider that a soundcard may be used only for transmit, and that
it should be possible to keep it open in that case as well.

[sm0svx]

Actually there already is a function Async::AudioDevice::isFullDuplexCapable() that report if a sound card is full duplex capable or not. The only thing left is to implement the logic in LocalTx. It's probably pretty simple to do.

[Dloranger]

I think this might fix one of the issues I have been fighting with high channel count sound cards, is there any plans to fix it?

also, I don't mind experimenting a bit.

Is this roughly the correct place to edit in the new code, line 887 of LocalTx.cpp?

[pe1chl]

Unfortunately there appears to be little development.
When you want to try a solution external to svxlink, look at the possibilities of alsa configuration
(via the file /etc/asound.conf) where you can setup complicated structures of plugins to route the
audio from virtual soundcards to the physical card.
E.g. with "dmix" you can create a mixer that combines the outputs of several sessions into a
single card, translating channel numbers along the way. Maybe you can solve your problem
with that. We use dsnoop and dmix to run different instances of svxlink and remotetrx alongside
using shared soundcards.

[Dloranger]

I am using the alsa stuff already, but alas, it is not being predictable in terms of getting stuff to play nicely. I will keep plugging (pun intended) along and see if I can make some headway, was just hoping someone might know roughly what is going on as I have been fighting with this for about a year on and off with multiple sound card types.

[sm0svx]

Latest master may solve this issue. Keep audio devices open by setting AUDIO_DEV_KEEP_OPEN=1 in a local RX or TX section. However, audio devices does not open immediately when the application starts but rather on first use.

Reopen issue if unresolved.

[dl1hrc]

please could you explain why we do not open the audio device and remain it open until SvxLink will be closed? What is the advantage of doing it this way?

[pe1chl]

now the issue has been re-opened anyway: also note that not opening the device immediately but only on first use does not solve our issue. it may solve other user's problems (those that have unreliable drivers that fail when opened and closed repeatedly) but it still does not work nicely with loopback devices, which need to get their configuration at the start.

[sm0svx]

This was the easiest solution right now to solve the issue with the Fe-Pi audio device. The audio device will be kept open until SvxLink exits but it will not open until first use.

[sm0svx]

It will probably not take much to resolve this issue as well. I'll have a quick look.

[sm0svx]

Happy now? ;-)

[pe1chl]

You have again updated it?
It is nice to see that you have come back to developing svxlink after a long silence, but by now we have fallen back so far from the head version (and cannot switch a single system due to the remotetrx protocol incompatibility) that I can no longer do quick tests of new functionality.
First we have to be convinced that the head version is stable and then we will have to do an en-masse update of systems.
Currently it is much too hot for that, here.

[sm0svx]

Yes, updated again: 0ea6db9. It now opens the audio device when the tx/rx object is created.

I'll close this issue for now. Just reopen it if it still does not work when you get time/temperature to test it.