From: David Wright <deb...@lionunicorn.co.uk>
Date: Wed, 29 Sep 2021 22:35:11 -0500
> ... your case is like playing it later by pressing a key.
Acknowledged.
> As for the gain, you might always start at some default, but it would
> surely be useful to be able to adjust it for mumblers and shouters
> while it was playing.
>
> You can of course just play the message with play, but there are
> advantages in popping up a player of some sort; for example, you
> can jog it backwards if you miss, say, an unclear word, and jog it
> forward if you're replaying a somewhat rambling message.
Keeping in mind for future use, thanks.
> It depends how imaginative you want to be about setting it up.
> I'd start with the ~/a42.WAV business. If VoIP calls are being
> recorded, I'd use a fixed directory, with files named by the
> calls' starting times, like 2021-09-29-123456.wav. That would
> give the flexibility to play/skip/delete messages in some sort
> of circular fashion with a minimal number of key bindings.
For interest, I use the Diamondcard PSTN-VoIP gateway service.
https://en.wikipedia.org/wiki/Public_switched_telephone_network
https://en.wikipedia.org/wiki/Voice_over_IP
https://www.diamondcard.us/
They name a voice message dddddddddd.WAV. To my understanding
dddddddddd is just a serial number. Haven't broached the time
notation to them.
According to a configuration, messages are sent to my email address. I
can change the name of the attachment after receiving. Currently
delete the first 8 digits and prefix "a". Hence the example a42.WAV.
An old message can be overwritten but it's rare and never been a
concern. The bigger chore is deleting old messages.
> As for what happens when you press your play key, it would run
> a script that would first set the audio controls to a set of
> initial values. These have been determined using alsamixer when
> setting this up (see top of post), and are set with commands like
>
> amixer -c "$Card" -- sset "Speaker" 70% on
>
> where $Card is the appropriate card number. The script would then
> run play (which you've cracked) or sox (where "default" doesn't
> point to the desired output device) on an appropriate file.
Keeping in mind for future.
> $ sox -q foo.wav -t alsa plughw:0 (my AiO PC)
> $ sox -q foo.wav -t alsa plughw:PCH (the same, using card name)
> $ sox -q foo.wav -t alsa plughw:PCH,0 (this AiO's PCH only has one
> device: 0)
> $ sox -q foo.wav -t alsa plughw:XXX
man sox has "-t, --type FILE-TYPE" and cites soxformat(7) which has
these examples.
" alsa (optional)
Advanced Linux Sound Architecture device driver; supports both
playing and recording audio. ALSA is only used in Linux-based
operating systems, though these often support OSS (see below) as
well. Examples:
sox infile -t alsa
sox infile -t alsa default
sox infile -t alsa plughw:0,0
sox -b 16 -t alsa hw:1 outfile
See also play(1), rec(1), and sox(1) -d."
> I think this thread has been around for a couple of years now.
> I assume the penny dropped that names like Live and ICH5 are
> the persistent items you were looking for.
Acknowledged but using the names properly is non-trivial, for me at
least. A self-inflicted difficulty was using play rather than sox.
According to the manual, play doesn't have outfile. Hence the
monkeying with shell and environment variables. Better to use sox and
specify outfile directly.
I'll hypothesize that alsa devices aren't represented in /dev/.
According to
https://en.wikipedia.org/wiki/Advanced_Linux_Sound_Architecture
ALSA was initially released in 1998. According to
https://en.wikipedia.org/wiki/Udev udev was initially released in
2003. In Debian releases, udev isn't applied to alsa devices.
The official manuals have plenty of dense information but a
wiki.debian.org/sox could explain elementary concepts and provide
useful examples.
Thx, ... P.
--
48.7693 N 123.3053 W
mobile: +1 778 951 5147
VoIP: +1 604 670 0140
