A Stupid Problem With Playback
Acording to the book, I’m supposed to put things into what Asterisk thinks is its default audio file location, /var/lib/asterisk/sounds, and I’m supposed to be able to create a custom directory off of that path and use it in a relative-syntax way in the Playback directive, like so:
…
same => n,Playback(mysounds/mygreeting)
I’m here to tell ya, it doesn’t work on my system. However, if I write:
same => n,Playback(/var/lib/asterisk/sounds/mydir/mygreeting)
it works fine. Where is the default directory defined? I search every configuration file and found no such definition.
And then there was this: When I finally got my system working after all the connectivity and extension-not-found and endpoint-not-found nonsense straightened out, I of course tried the hello-world standard startup test. It didn’t work. Why? Because when you install Asterisk version 16
from the Debian distro site, you don’t get the core sounds, and when you do install the core sounds package, they don’t get put into
/var/lib/asterisk/sounds. Oh no–they get put into
/usr/share/asterisk/sounds. In there, I found several directories such as ‘en’ and ‘en_us’. I copied the files from the en_us directory into
/var/lib/asterisk/sounds and hello-world worked fine. So then I created a custom directory and put my own things in it, changing the Playback statement to the first one above, and it failed. I have to specify the full path instead of using the relative syntax version thereof. This is technically not a problem, more just a curiosity as to why it didn’t work the way I thought it’s supposed to.
—
6 thoughts on - A Stupid Problem With Playback
/var/lib/asterisk/sounds/en Relative paths are relative to your language-specific directory.
A great reason to avoid Asterisk packages and compile from source instead. You’ll save yourself a lot of headaches.
—
copying the sound files out of /usr/share/asterisk/sounds/en_us into
/var/lib/asterisk/sounds–I don’t even know for sure that hello-world was playing from the /var path and not the /usr path. Good idea to test that and see what’s really going on. I think I set too much store by these books sometimes. But when that’s all I have, I tend to go with what I know, and if the book is all I know … well …
That’s how I started, by trying to build version 18 from source. It failed. Colossally. The compile of sources would run for a while, then the machine would crash spectacularly–I mean, not just hang or reboot. It actually turned itself off. I tried it several times, and each time it failed in the same way, but at a different spot in the compile process. If ever I could figure out a way to trace that one down, I
would. It was the strangest thing. So I gave up trying to build from source and went to the distro. Truth to tell, I’d rather have been able to build it from source because then I could follow my book more closely, and I enjoy and am familiar with working with SQL. I understood perfectly what the book was telling me to do and how it would all integrate with configuring Asterisk. Very strange indeed. Maybe I’ll try a later version and see what happens.
—
This sounds like your machine is defective in some major way. Granted, compiling software is pretty intensive, but your machine shouldn’t just crash. I would try to figure that out. Is this a VM / bare metal? Have you tried this on another machine?
—
It’s probably eight or nine years old now, an ASRock motherboard with I
don’t even know what on it in the way of processor speed or power. I
should probably pick up another machine but I can’t justify the expense because it’s only for play, FTP, and running this Asterisk project, which is complete enough now that I don’t have to mess with it any more. Who knows–it might even wind up on a spare Raspberry Pi 4, in which case this whole tower can just go away.
—
It’s not a manufacturer with which I’m familiar, either.
8 or 9 years isn’t really that old. I run Asterisk on OptiPlex towers that are 20 years old, and it works really well. I’ve actually had more issues with things that are more compact, like rack servers. What’s important is to have a working, compatible machine in good condition.
Some general observations:
– The CPU doesn’t need to great, but it should be sufficient. Any desktop CPU from the last 20 years should be perfectly adequate.
– Compiling can run into hitches if you don’t have enough memory on your machine. On machines with 1 GB of RAM or less, for example, I’ve found that swap space is mandatory to compile very large files (e.g. chan_sip.c). Otherwise, gcc will just get killed by the kernel eventually. But you need far more memory when compiling than when Asterisk itself is running. You could allocate a bunch of swap and deallocate it after you’re done.
For just SIP stuff, lots of people have used Pis and it works great for them, so that might not be a bad idea. You definitely don’t need a new machine though. Any old PC lying around since ~2000 or so will probably do just fine. If you happen to have a spare handy, you could try it out.
—
A ‘4 is probably way more than you need. A Pi Zero W or a Pi Zero 2 W
would probably do. ($15 plus case and spare USB wall wart.)
You may be able to justify the expense just on power savings. (Electricity in San Diego is $0.51/kWh.)
—
Thanks in advance,
————————————————————————-
Steve Edwards sedwards@sedwards.com Voice: +1-760-468-3867 PST
https://www.linkedin.com/in/steve-edwards-4244281
—