Audio not heard in remote party
I was having the problem where audio was not heard in the remote party.
Looking at a topic in the forum (http://www.celliax.org/node/121) I tried adding noload=>alsa and oss . Then using alsamixer I raised the volumes (unmuted, etc). That helped, I started listening something. I did the Echo test and my voice would come back surrounded by a LOT of noise.
I tried default:0 in celliax but the one that worked was plughw:0
Now I will play for a while with the gain setting in celliax.conf and with the alsamixer.
The sound config of computer is never very clear to me. As for what I saw, ALSA is a layer above OSS that let's you share the sound device among many processes (OSS only grants exclusive access).
Asterisk can use OSS or ALSA, but this is only for the Console. As we don't need the Console to play/capture audio, we can disable both channels (in modules.conf).
Celliax uses ALSA. That means that:
1. no process should have accessed the sound card before directly via OSS (locking it)
2. any other process that uses ALSA can still play sound. If a celliax phone call is active, that sound will be heard by the remote call party.
Are these statements correct? Is it necessary that asterisk does not load chan_alsa for celliax to work?
It would be nice to have an example of what would be a common configuration of alsamixer. I am set up with trixbox (centos + linux kernel 2.6.9) and the machine is just meant to run celliax.
But I wouldn't be suggesting this if I knew more about the sound components.
regards,
aram
Search
Active topics
New topics
Popular content
Today's:
Planet Asterisk
Syndicate
what is the best way to
what is the best way to ensure the audio cable is ok?
Ciao Aram, I'll try to
Ciao Aram, I'll try to clarify some things:
ALSA and OSS are complete separate sound "systems" in Linux, and they can't cohexist.
Alsa is only for linux, oss is for all unix flavors.
In Linux, Oss is the "old" system, while alsa is the "new" system.
You can have alsa or oss, not both.
But alsa has an oss emulation, and so programs that are compiled to access sound through oss can be executed in an alsa environment.
With recent linux distros you almost always have alsa, with oss emulation for compatibility with old programs.
Oss gives exclusive access to soundcard to one only program at time, and the oss emulation has the same behavior.
Alsa give shared access, but only if you use the "default:n" device. If you use the "plughw:n" device, you have exclusive access. So, if you plan to use the sound not only for asterisk, use the "default:n" device.
For best test, in alsamixer mute all that you do not use. Maybe you want to activate the microphone 20db gain, if the remote party hear you too faible.
->start ranting
Unfortunately alsa in Linux is maybe the most obscure matter of the entire operating system, is horribly documented, overly complicated, the programming API is a nightmare, etc... In my opinion is a very very sorry situation. I can't understand why is alsa so horrible (while in windows is so easy to have sound interaction... I added the windows sound support to chan_celliax in a little while, and never touched it again, while the alsa part is a never ending story).
->end ranting
please post any more info-clarification I can give on this matter
an audio cable works or is
an audio cable works or is broken. It is just a wire, so if you want you can test its continuity with a tester for electricians or electronic engineers.
Thank you very much for your
Thank you very much for your explanation. At least the basics are more clear to me now.
I have good news regarding my issue. Look's solved!
Here's what I've done:
1) Rerun the livecd 0.46 that I knew was working fine.
2) Sreenshoted the alsamixer screen
3) Removed the cd and restarted using my centos
4) Set the alsamixer config the same as what I had in the screenshot
Tried it again, no luck. Audio was still one way (remote party got no sound). After seeing the send audio wait failed ERROR in the Console, I went to see that section of code and I saw the comment saying "//FIXME period in config" referring to alsa_period_size property in celliax.conf
So I started trying asterisk using different values for that property. I tried with 30, 70, 100, 130, 160 (every test between asterisk restarts)
For most cases I could see errors in the Console, some saying 'Write error: Network is down' others saying 'Write error: Unknown error 130' , others saying 'Write error: Too many levels of symbolic links'. Error logs corresponded to the alsa_write method...
Even though the error logs, for some cases I could hear some noise/voice like in chunks.
I think using the 30 gave me some hope, but at the same time I got a segmentation fault crash (this is the error I tried to report before but didn't know how to reproduce at that time).
The story ended when I tried the higher alsa_period_size that gave me some audio: 160
From 161 and above (default is 170) I get NO audio at all, and no error log. Well, I was geting an error log but I wasn't paying much attention to it:
[May 27 03:01:19] ERROR[12716] chan_celliax.c: [b78d6bb0][ERROR 3842 ][nicephone ][ 6, 3, 6, 0] audio play wait failed: Invalid argument
This lines seems to appear only once per asterisk run. Maybe if it mentioned the property will help future users having the same problem.
The other experience I want to share is configuring the alsa components volume. It took me some time to realize the important components to configure were the Mic, Front and Front Mic . In particular my pc has audio jacks in the front and I thought those were the Front and Front Mic, but wrong! Front and Front Mic were the sound cards jack in the back of my pc, where I have the c350 audio cables plugged.
Now everything looks to be working, audio is listened ok at both sides... I noticed the Echo test does Echo forever (but I don't really care right now :)
CIao, Ciao, ciao.... :)
for what is my experience,
for what is my experience, you have to set the fragment size to 160 or 170, no other values... Maybe this has to be explicitly said, but I was not sure about... maybe on some soundcards it has to be different...
the errors with stupid description (network, too many symbolic links, etc) seems to be a problem in alsa itself, they are generated by the snd_strerror() that is an alsa function to interpret the result of a previous (failed) alsa function invocation (snd_pcm_wait(), in this case).
All the same, there is no a uniform naming of alsa mixer components, they vary from soundcard to soundcard... :(
It is a kind of nightmare to have alsa things setup correctly... the good news is that once it is working, it keeps working reliably!
How to install Celliax in
How to install Celliax in Trixbox 2.2: http://www.celliax.org/node/313