January 1, 2015 at 13:48Sound Mixing in Cubian
When I was faced with the task of playing several audio files on Cubian in parallel , I still had no idea. For many years in Linux there has been no problem with sound mixing: ALSA can do this natively, and many sound servers offer their services for every taste and budget .
It turned out that there is a problem, and it is more extensive than I originally thought.
So, for the first time I came across the problem in question when I wrote an application in QT. Phonon was chosen as the sound API. And, as soon as I started the application for the first time, I discovered that the audio drivers from sunxi do not know how to mix sound. Discouraged by this circumstance, I set the pulse ... and did not get any result. More precisely, the results were different: either clicks and wheezing, then complete silence. Depending on what other packages were installed. Having tried all available sound demons (and there weren’t so many of them in Debian), I returned to the pulse, because the problem had not been resolved and, obviously, lay somewhere deeper.
For those who have never gone into pulseaudio settings, I’ll do a little
Because in the context of a more global problem, some unobvious moments can greatly complicate life.
When the first iteration did not bring the desired result, I decided to find out what Google knows about this problem. Google answered meekly and reluctantly. I could only find out that you should not use the phonon vlc-backend, you should use gstreamer (for me this was somewhat surprising, because I always considered vlc to be the main media engine).
As a result, the first problem was solved by completely black magic: 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 on one command, and on the other, play the audio file. The first part is solved by an asterisk with chan_alsa. But chan_alsa completely occupies the device and does not return until you unload the module. Therefore, again the pulse.
This time everything turned out to be funnier: chan_alsa does something with the pulse that until you unload it, the sound does not play either by itself or by any other application. When you start a pulse with a detailed debug, you manage to catch an error, the whole point of which boils down to "you have crooked card drivers, send this data to the driver developers." Well, since the problem is in the ALSA drivers, I decided to try OSS. This time there was even a sound, but with such interruptions that the idea immediately lost its meaning.
Since all this happened against the background of the already solved first problem and sox playing well, 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 exactly repeated with the softphone, there were suspicions that it was not a specific application, but ... well, maybe in resampling the voip audio stream in the native PCM card.
Since there were no tasks to play sound simultaneously from different sources in this case, and linphone takes up the device only for the duration of direct sound playback, it was decided to remove the pulse from the circuit.
Despite the fact that the problem itself was solved, the problem of outputting the voip audio stream through the pulse remained. And if anyone finds a solution to it, I will be very grateful.
It turned out that there is a problem, and it is more extensive than I originally thought.
Problem number 1. Solved. Phonon and pulseaudio
So, for the first time I came across the problem in question when I wrote an application in QT. Phonon was chosen as the sound API. And, as soon as I started the application for the first time, I discovered that the audio drivers from sunxi do not know how to mix sound. Discouraged by this circumstance, I set the pulse ... and did not get any result. More precisely, the results were different: either clicks and wheezing, then complete silence. Depending on what other packages were installed. Having tried all available sound demons (and there weren’t so many of them in Debian), I returned to the pulse, because the problem had not been resolved and, obviously, lay somewhere deeper.
For those who have never gone into pulseaudio settings, I’ll do a little
retreat
The pulse can work in two modes: system and user. Let's consider both separately:
1. System. Not recommended on multi-user 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 takes an audio device and gives access (including to the sound settings) to all users from the pulse-access group (and not pulse, this is important).
To enable this mode in debian, you need to include the parameter in the / etc / default / pulseaudio file : PULSEAUDIO_SYSTEM_START = 1. Next, delete all users except pulse from the audio group. We nail all session instances of pulseaudio, if any, and start the pulseaudio service. So that the user can use the sound, add it to the pulse-access group .
2. Sessional. Works on both multi-user and embedded systems. But you need to understand that if the drivers of your card do not know how to mix, only one user can play sound at any given moment. By default, this mode is enabled in the debian. In order for the user to interact with the sound card, it must be added to the audio group
1. System. Not recommended on multi-user 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 takes an audio device and gives access (including to the sound settings) to all users from the pulse-access group (and not pulse, this is important).
To enable this mode in debian, you need to include the parameter in the / etc / default / pulseaudio file : PULSEAUDIO_SYSTEM_START = 1. Next, delete all users except pulse from the audio group. We nail all session instances of pulseaudio, if any, and start the pulseaudio service. So that the user can use the sound, add it to the pulse-access group .
2. Sessional. Works on both multi-user and embedded systems. But you need to understand that if the drivers of your card do not know how to mix, only one user can play sound at any given moment. By default, this mode is enabled in the 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 greatly complicate life.
When the first iteration did not bring the desired result, I decided to find out what Google knows about this problem. Google answered meekly and reluctantly. I could only find out that you should not use the phonon vlc-backend, you should use gstreamer (for me this was somewhat surprising, because I always considered vlc to be the main media engine).
As a result, the first problem was solved by completely black magic: installing the gstreamer0.10-plugins-ugly package . And the phonon began to play.
Problem number 2. Unresolved. VoIP and pulseaudio
The second task was to send a stream from VoIP to the audio output on one command, and on the other, play the audio file. The first part is solved by an asterisk with chan_alsa. But chan_alsa completely occupies the device and does not return until you unload the module. Therefore, again the pulse.
This time everything turned out to be funnier: chan_alsa does something with the pulse that until you unload it, the sound does not play either by itself or by any other application. When you start a pulse with a detailed debug, you manage to catch an error, the whole point of which boils down to "you have crooked card drivers, send this data to the driver developers." Well, since the problem is in the ALSA drivers, I decided to try OSS. This time there was even a sound, but with such interruptions that the idea immediately lost its meaning.
Since all this happened against the background of the already solved first problem and sox playing well, 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 exactly repeated with the softphone, there were suspicions that it was not a specific application, but ... well, maybe in resampling the voip audio stream in the native PCM card.
Since there were no tasks to play sound simultaneously from different sources in this case, and linphone takes up the device only for the duration of direct sound playback, it was decided to remove the pulse from the circuit.
Despite the fact that the problem itself was solved, the problem of outputting the voip audio stream through the pulse remained. And if anyone finds a solution to it, I will be very grateful.