Sound Mixing in Cubian
When I was faced with the task of simultaneously playing several audio files on Cubian , I had no idea about this. For many years in Linux there is no sound mixing problem: and ALSA is able to do this natively, and many sound servers offer their services for every taste and wallet .
It turned out that there is a problem, and it is more extensive than I originally intended.
So, for the first time I ran into this problem when I wrote an application on QT. Phonon was chosen as the sound API. And, as soon as I started the application for the first time, as I discovered that the audio drivers from sunxi do not know how to mix the sound. Discouraged by this circumstance, I set the pulse ... and did not get any result. More precisely, the results were different: then clicks and wheezing, then complete silence. Depending on what other packages were installed. Having tried all the available sound demons (and there were not so many of them in the debian), I returned to the pulse, because the problem did not dare and, obviously, lay somewhere deeper.
For those who never went into the settings of pulseaudio, I will do a little
Because in the context of a more global problem, some unobvious moments can make life difficult.
')
When the first iteration did not bring the desired result, I decided to find out what Google knows about this problem. Google responded sparingly and reluctantly. I could find out only that the phonon vlc-backend should not be used, it is necessary to use gstreamer (for me it was somewhat surprising, because I always considered vlc the main media engine).
As a result, the first problem was solved by absolutely black magic: by installing the gstreamer0.10-plugins-ugly package. And the phonon began to play.
The second task was to send a stream from VoIP to the audio output, and to play an audio file on the other. The first part is solved by an asterisk with chan_alsa. But chan_alsa completely occupies the device and does not give it away until you unload the module. Therefore, the pulse again.
This time everything turned out to be more fun: chan_alsa does something with the pulse that, until you unload it, the sound does not play either itself or any other application. When you start the pulse with a detailed debug it is possible to catch an error, the whole essence of which comes down to “you have driver curves for the card, send this data to the driver developers”. Well, since the problem is in the ALSA drivers, I decided to try OSS. This time the sound was even, but with such interruptions that the idea immediately lost its meaning.
Since all of this was happening against the background of the already solved first problem and the excellent playing sox, I thought that the problem was not so much in the drivers as in the asterisk module, and decided to replace it ... for example, with linphone. When the problem was exactly repeated with the softphone, suspicions arose that the matter was not in a specific application, but ... well, maybe in a resampling of a voice audio stream in a native PCM card.
Since there were no tasks to play the sound from different sources at the same time, and the linphone only takes the device for the duration of the sound itself, it was decided to remove the pulse from the circuit.
In spite of the fact that the problem itself was solved, the problem of output of the voice audio stream through the pulse remained. And if someone finds her solution, I will be very grateful.
It turned out that there is a problem, and it is more extensive than I originally intended.
Problem number 1. Solved. Phonon and pulseaudio
So, for the first time I ran into this problem when I wrote an application on QT. Phonon was chosen as the sound API. And, as soon as I started the application for the first time, as I discovered that the audio drivers from sunxi do not know how to mix the sound. Discouraged by this circumstance, I set the pulse ... and did not get any result. More precisely, the results were different: then clicks and wheezing, then complete silence. Depending on what other packages were installed. Having tried all the available sound demons (and there were not so many of them in the debian), I returned to the pulse, because the problem did not dare and, obviously, lay somewhere deeper.
For those who never went into the settings of pulseaudio, I will do a little
retreat
Pulse can work in two modes: system and user. Consider both separately:
1. Systemic. Not recommended on multiuser systems. Why - see the documentation, there about it in detail. In the case of embedded systems, it is quite suitable and sometimes even optimal. The daemon itself occupies an audio unit and gives access (including sound settings) to all users from the pulse-access group (and not pulse, this is important).
To enable this mode in debian it is necessary to enable the parameter: / PULSEAUDIO_SYSTEM_START = 1 in the / etc / default / pulseaudio file. Next, remove all users from the audio group, except pulse . We beat all the session instances of pulseaudio, if any, and start the pulseaudio service. So that the user can use the sound, we add it to the pulse-access group.
2. Session. It works on both multi-user and embedded systems. But you have to understand that if the drivers of your card are not able to mix, only one user can play the sound at any given moment. By default, this mode is enabled in Debian. In order for the user to interact with the sound card, it must be added to the audio group.
1. Systemic. Not recommended on multiuser systems. Why - see the documentation, there about it in detail. In the case of embedded systems, it is quite suitable and sometimes even optimal. The daemon itself occupies an audio unit and gives access (including sound settings) to all users from the pulse-access group (and not pulse, this is important).
To enable this mode in debian it is necessary to enable the parameter: / PULSEAUDIO_SYSTEM_START = 1 in the / etc / default / pulseaudio file. Next, remove all users from the audio group, except pulse . We beat all the session instances of pulseaudio, if any, and start the pulseaudio service. So that the user can use the sound, we add it to the pulse-access group.
2. Session. It works on both multi-user and embedded systems. But you have to understand that if the drivers of your card are not able to mix, only one user can play the sound at any given moment. By default, this mode is enabled in Debian. In order for the user to interact with the sound card, it must be added to the audio group.
Because in the context of a more global problem, some unobvious moments can make life difficult.
')
When the first iteration did not bring the desired result, I decided to find out what Google knows about this problem. Google responded sparingly and reluctantly. I could find out only that the phonon vlc-backend should not be used, it is necessary to use gstreamer (for me it was somewhat surprising, because I always considered vlc the main media engine).
As a result, the first problem was solved by absolutely black magic: by installing the gstreamer0.10-plugins-ugly package. And the phonon began to play.
Problem number 2. Unsolved VoIP and pulseaudio
The second task was to send a stream from VoIP to the audio output, and to play an audio file on the other. The first part is solved by an asterisk with chan_alsa. But chan_alsa completely occupies the device and does not give it away until you unload the module. Therefore, the pulse again.
This time everything turned out to be more fun: chan_alsa does something with the pulse that, until you unload it, the sound does not play either itself or any other application. When you start the pulse with a detailed debug it is possible to catch an error, the whole essence of which comes down to “you have driver curves for the card, send this data to the driver developers”. Well, since the problem is in the ALSA drivers, I decided to try OSS. This time the sound was even, but with such interruptions that the idea immediately lost its meaning.
Since all of this was happening against the background of the already solved first problem and the excellent playing sox, I thought that the problem was not so much in the drivers as in the asterisk module, and decided to replace it ... for example, with linphone. When the problem was exactly repeated with the softphone, suspicions arose that the matter was not in a specific application, but ... well, maybe in a resampling of a voice audio stream in a native PCM card.
Since there were no tasks to play the sound from different sources at the same time, and the linphone only takes the device for the duration of the sound itself, it was decided to remove the pulse from the circuit.
In spite of the fact that the problem itself was solved, the problem of output of the voice audio stream through the pulse remained. And if someone finds her solution, I will be very grateful.
Source: https://habr.com/ru/post/247205/
All Articles