Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #240488 > unrolled thread

Re: Persistent names for audio devices.

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Persistent names for audio devices. peter@easthope.ca - 2021-09-28 18:00 +0200
    Re: Persistent names for audio devices. ghe2001 <ghe2001@protonmail.com> - 2021-09-28 19:30 +0200
      Re: Persistent names for audio devices. peter@easthope.ca - 2021-09-28 23:40 +0200
        Re: Persistent names for audio devices. David Wright <deblis@lionunicorn.co.uk> - 2021-09-29 01:40 +0200
          Re: Persistent names for audio devices. peter@easthope.ca - 2021-09-29 22:40 +0200
            Re: Persistent names for audio devices. David Wright <deblis@lionunicorn.co.uk> - 2021-09-30 05:40 +0200
              Re: Persistent names for audio devices. peter@easthope.ca - 2021-09-30 19:10 +0200
    Re: Persistent names for audio devices. Greg Wooledge <greg@wooledge.org> - 2021-09-28 19:40 +0200
      Re: Persistent names for audio devices. Nils <tuxifan@posteo.de> - 2021-09-28 20:00 +0200
        Re: Persistent names for audio devices. Tixy <tixy@yxit.co.uk> - 2021-09-28 21:20 +0200
      Re: Persistent names for audio devices. peter@easthope.ca - 2021-09-29 00:10 +0200
        Re: Persistent names for audio devices. Greg Wooledge <greg@wooledge.org> - 2021-09-29 00:20 +0200
        Re: Persistent names for audio devices. <tomas@tuxteam.de> - 2021-09-29 09:00 +0200
          Re: Persistent names for audio devices. David <bouncingcats@gmail.com> - 2021-09-29 13:00 +0200

#240488 — Re: Persistent names for audio devices.

    From: peter@easthope.ca
    Date: Sat, 31 Jul 2021 09:52:21 -0700
> In spite of the warning, sound is produced.  Good!  Might have a 
> reliable way to hear voice messages.
> 
> CONCLUSIONS
> 
> Audio messages can be interpreted.  Eg.,
> set AUDIODEV=plughw:CARD=ICH5,DEV=0; play m94.WAV

Hasty reply.  In further use, didn't always work.  I removed the PCI 
sound card, removed the plastic cover from the sockets on the system 
board and connected speakers.  Subsequently commands such as this 
always work.

set AUDIODEV=plughw:CARD=ICH5,DEV=0 ; play a42.WAV

SPECULATION

The PCI card was meant to give better quality sound and  was operated 
properly by the Windows system present when the machine was sold by 
Dell.  When multiple sound devices exist, Linux still doesn't identify 
devices properly. 

REVISED CONCLUSION

Upstream documentation relating to sound hardware and software needs 
attention. Software also needs debugging.  

Regards,                  ... P.

-- 
48.7693 N 123.3053 W
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140

[toc] | [next] | [standalone]

#240494

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, September 28, 2021 9:19 AM, <peter@easthope.ca> wrote:

> From:peter@easthope.ca
> Date: Sat, 31 Jul 2021 09:52:21 -0700
>
> > In spite of the warning, sound is produced. Good! Might have a
> > reliable way to hear voice messages.
> > CONCLUSIONS
> > Audio messages can be interpreted. Eg.,
> > set AUDIODEV=plughw:CARD=ICH5,DEV=0; play m94.WAV
>
> Hasty reply. In further use, didn't always work. I removed the PCI
> sound card, removed the plastic cover from the sockets on the system
> board and connected speakers. Subsequently commands such as this
> always work.
>
> set AUDIODEV=plughw:CARD=ICH5,DEV=0 ; play a42.WAV
>
> SPECULATION
>
> The PCI card was meant to give better quality sound and was operated
> properly by the Windows system present when the machine was sold by
> Dell. When multiple sound devices exist, Linux still doesn't identify
> devices properly.
>
> REVISED CONCLUSION
>
> Upstream documentation relating to sound hardware and software needs
> attention. Software also needs debugging.

Try alsamixer.  You can select the audio device there.  It works for my


--
Glenn English

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsBzBAEBCAAGBQJhU0/hACEJEJ/XhjGCrIwyFiEELKJzD0JScCVjQA2Xn9eG
MYKsjDIaAAf8CkZhU3HG0ssH6wcOgnVWt4ZQHpEX4KwI8kltp9xMTq5aah7P
eoT+TxZ6xcib0wKyZCggu4ni1Yz+okFesZp6JNPheUQ5kIGkYYkJUk3JRRKt
ccKvgX5br6mqNAmhxL7oZ/F2VbwKxG3ksbe/RsYFqe08jWon6vt/lMI+Zv0v
GelKXltFxxuowDs8+k9dCAKqVoQ+hP6HTmevlVkpdFzLByXHCtP55GOSv2P+
W9Y/RCmtlpzoq5UisKORhzGUqaSHnDwUA7dcddnZ4ky4a9cZqJ/Pdta45/2p
Ha2nNQmqmeprT/HZAo3ZKKQa9SCmeMgRCmeRFlhRT9PN8sAD6SQMnw==
=MQeB
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#240516

    From: ghe2001 <ghe2001@protonmail.com>
    Date: Tue, 28 Sep 2021 17:24:57 +0000
> Try alsamixer.  You can select the audio device there.  It works for my

Thanks.

>From the alsamixer manual, 
"DESCRIPTION
       alsamixer is an ncurses mixer program for use with the  ALSA  soundcard
       drivers. It supports multiple soundcards with multiple devices."

A terminal with an ncurses display is necessary to listen to an audio message?

Now that the PCI sound card is gone, disambiguation appears to be unnecessary.
This command works. 
play a42.WAV

Something odd in the sox manual.
       -d, --default-device
              This  can  be  used  in  place of an input or output filename to
              specify that the default audio device (if  one  has  been  built
              into  SoX)  is to be used.  This is akin to invoking rec or play
              (as described above).

What is the sense in telling a software to use a default?  In absence of 
an output specification, what else would be used?

peter@joule:/home/peter$ sox  /home/peter/a42.WAV /dev/snd/pcmC0D0c
sox FAIL formats: can't determine type of `/dev/snd/pcmC0D0c'

Can sox specify a sound device for output? 

Thx,                 ... P.

-- 
48.7693 N 123.3053 W
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140

[toc] | [prev] | [next] | [standalone]

#240522

On Tue 28 Sep 2021 at 13:49:37 (-0700), peter@easthope.ca wrote:
>     From: ghe2001 <ghe2001@protonmail.com>
>     Date: Tue, 28 Sep 2021 17:24:57 +0000
> > Try alsamixer.  You can select the audio device there.  It works for my
> 
> >From the alsamixer manual, 
> "DESCRIPTION
>        alsamixer is an ncurses mixer program for use with the  ALSA  soundcard
>        drivers. It supports multiple soundcards with multiple devices."
> 
> A terminal with an ncurses display is necessary to listen to an audio message?

No, you'd use alsamixer where you were taking an active rôle during
record/playback, or for discovering, inspecting and setting up a
system. Typically, you'd play "an audio message", or anything else,
with some sort of application, unless it was a disembodied
notification, say.

Some applications include volume/balance controls and so on; others
don't. I have keys set up for adjusting the volume on the various
controls, using the multimedia keys XF86Audio{Mute,LowerVolume,RaiseVolume}
(F1/F2/F3 where not present), with Ctrl/Alt/Shift to select between
Master/Speakers/Headphones/PCM.

> Now that the PCI sound card is gone, disambiguation appears to be unnecessary.
> This command works. 
> play a42.WAV
> 
> Something odd in the sox manual.
>        -d, --default-device
>               This  can  be  used  in  place of an input or output filename to
>               specify that the default audio device (if  one  has  been  built
>               into  SoX)  is to be used.  This is akin to invoking rec or play
>               (as described above).
> 
> What is the sense in telling a software to use a default?  In absence of 
> an output specification, what else would be used?

How otherwise would you make explicit what you're happy to use
implicitly? (When I write a script, I try to be as explicit as
possible, avoiding short-cuts, abbreviations, assumptions, etc.)

> peter@joule:/home/peter$ sox  /home/peter/a42.WAV /dev/snd/pcmC0D0c
> sox FAIL formats: can't determine type of `/dev/snd/pcmC0D0c'
> 
> Can sox specify a sound device for output? 

Yes:    sox /home/peter/a42.WAV -t alsa default

I define a function that saves typing, which I use when I'm checking
effects/timings etc.

function soxy {
    [ -z "$1" ] && printf '%s\n' "Usage:	${FUNCNAME[0]} path-to/sound-file-of-any-type [trim 20 2]
	runs sox to play the file with any arguments given.
	The example is a reminder for arguments in full." >&2 && return 1
    local From="$1"
    shift
    sox -q "$From" -t alsa default "$@"
}

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#240593

Trimmed the reference list.  =8~)

    From: David Wright <deblis@lionunicorn.co.uk>
    Date: Tue, 28 Sep 2021 18:31:34 -0500
> No, you'd use alsamixer where you were taking an active rôle during
> record/playback, or for discovering, inspecting and setting up a
> system. Typically, you'd play "an audio message", or anything else,
> with some sort of application, unless it was a disembodied
> notification, say.
> 
> Some applications include volume/balance controls and so on; others
> don't. I have keys set up for adjusting the volume on the various
> controls, using the multimedia keys XF86Audio{Mute,LowerVolume,RaiseVolume}
> (F1/F2/F3 where not present), with Ctrl/Alt/Shift to select between
> Master/Speakers/Headphones/PCM.

Understood, but to listen to an audio message from VoIP (not opera) a 
simple command should suffice. (play ~/a42.WAV) Speakers rather than 
headphones for a voice message.  I'd rather not  adjust volume except 
maybe "play ~/a42.WAV gain 1".  A typical message is "Please call J. 
Doe."  In a worst case I might shut off the RCA AM radio made in 1960 
to hear the message better.  =8~)  Seems we're at crossed purposes 
here.

> How otherwise would you make explicit what you're happy to use
> implicitly?

No offense but isn't that analogous to saying to a ten year old 
"Johnny, please eat your lunch with your mouth."  =8~) 

A default which isn't unique is a bad default.  If it is unique, 
there's nothing to disambiguate.  Crossed purposes again?  

> (When I write a script, I try to be as explicit as
> possible, avoiding short-cuts, abbreviations, assumptions, etc.)

Absolutely good policy.  I try to follow it also but tend to fail.  =8~)

> sox /home/peter/a42.WAV -t alsa default

Good. 

The machine here has sound hardware on the system board.  Also it can 
have a PCI sound card.  Sound devices reported here. 
https://lists.debian.org/debian-user/2021/07/msg01272.html

Assume speakers are plugged to output on the system board; headphones 
plugged to the PCI card.  A Linphone ring and a voice message (play 
~/a42.WAV) should always go to the speakers.  VoIP I/O (a 
conversation) and ring can be configured in Linphone; no problem.  
"play ~/a42.WAV" delivering to the headphones in random cases is an 
unacceptable failure. How would you make it work without frequent 
configuration adjustments?  

Thanks,                        ... P.




-- 
48.7693 N 123.3053 W
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140

[toc] | [prev] | [next] | [standalone]

#240616

On Wed 29 Sep 2021 at 12:25:49 (-0700), peter@easthope.ca wrote:
>     From: David Wright <deblis@lionunicorn.co.uk>
>     Date: Tue, 28 Sep 2021 18:31:34 -0500
> > No, you'd use alsamixer where you were taking an active rôle during
> > record/playback, or for discovering, inspecting and setting up a
> > system. Typically, you'd play "an audio message", or anything else,
> > with some sort of application, unless it was a disembodied
> > notification, say.
> > 
> > Some applications include volume/balance controls and so on; others
> > don't. I have keys set up for adjusting the volume on the various
> > controls, using the multimedia keys XF86Audio{Mute,LowerVolume,RaiseVolume}
> > (F1/F2/F3 where not present), with Ctrl/Alt/Shift to select between
> > Master/Speakers/Headphones/PCM.
> 
> Understood, but to listen to an audio message from VoIP (not opera) a 
> simple command should suffice. (play ~/a42.WAV) Speakers rather than 
> headphones for a voice message.  I'd rather not  adjust volume except 
> maybe "play ~/a42.WAV gain 1".  A typical message is "Please call J. 
> Doe."  In a worst case I might shut off the RCA AM radio made in 1960 
> to hear the message better.  =8~)  Seems we're at crossed purposes 
> here.

Not really. A disembodied notification is like an answerphone that
plays a message out loud during the call, whereas your case is like
playing it later by pressing a key.

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.

> > How otherwise would you make explicit what you're happy to use
> > implicitly?
> 
> No offense but isn't that analogous to saying to a ten year old 
> "Johnny, please eat your lunch with your mouth."  =8~) 
> 
> A default which isn't unique is a bad default.  If it is unique, 
> there's nothing to disambiguate.  Crossed purposes again?  

More like "Breathe through your nose!"

> > (When I write a script, I try to be as explicit as
> > possible, avoiding short-cuts, abbreviations, assumptions, etc.)
> 
> Absolutely good policy.  I try to follow it also but tend to fail.  =8~)
> 
> > sox /home/peter/a42.WAV -t alsa default
> 
> Good. 
> 
> The machine here has sound hardware on the system board.  Also it can 
> have a PCI sound card.  Sound devices reported here. 
> https://lists.debian.org/debian-user/2021/07/msg01272.html
> 
> Assume speakers are plugged to output on the system board; headphones 
> plugged to the PCI card.  A Linphone ring and a voice message (play 
> ~/a42.WAV) should always go to the speakers.  VoIP I/O (a 
> conversation) and ring can be configured in Linphone; no problem.  
> "play ~/a42.WAV" delivering to the headphones in random cases is an 
> unacceptable failure. How would you make it work without frequent 
> configuration adjustments?  

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.

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.

Examples of the latter would be:

$ 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

XXX could be any of Live, ICH5, Set (headphones), but not
U0x46d0x807 I think, as that looks like only an input.
Alsamixer would help you determine which is which, if you don't
already know. (I thought you had already determined this in, eg,
https://lists.debian.org/debian-user/2021/08/msg00133.html
but it's difficult to follow both the threading and which
commands make noises from which actual physical things).

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.

Disclaimers: I don't know anything about the hardware you're using,
and I've ignored your pulseaudio because I don't use it.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#240669

    From: David Wright <deblis@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

[toc] | [prev] | [next] | [standalone]

#240495

On Tue, Sep 28, 2021 at 08:19:26AM -0700, peter@easthope.ca wrote:
> > CONCLUSIONS
> > 
> > Audio messages can be interpreted.  Eg.,
> > set AUDIODEV=plughw:CARD=ICH5,DEV=0; play m94.WAV
> 
> Hasty reply.  In further use, didn't always work.  I removed the PCI 
> sound card, removed the plastic cover from the sockets on the system 
> board and connected speakers.  Subsequently commands such as this 
> always work.
> 
> set AUDIODEV=plughw:CARD=ICH5,DEV=0 ; play a42.WAV

Are you in csh/tcsh?  If you're in a more "normal" shell (bash or zsh),
that set command doesn't do anything useful.  Certainly nothing that
would affect the play command.

Even if you're in (t)csh, my understanding is that "set" sets shell
variables, and you need "setenv" to set environment variables (which
could conceivably affect the play command).  So, even in (t)csh, I
don't see how your set command is supposed to work.

Other shells... rc? fish?  I don't know these.  I have no idea what
the set command does in them.

[toc] | [prev] | [next] | [standalone]

#240498

[Multipart message — attachments visible in raw view] — view raw

I agree. In the "normal" shells, you need to use "export" instead of "set"!

Am 28. September 2021 19:32:02 MESZ schrieb Greg Wooledge <greg@wooledge.org>:
>On Tue, Sep 28, 2021 at 08:19:26AM -0700, peter@easthope.ca wrote:
>> > CONCLUSIONS
>> > 
>> > Audio messages can be interpreted.  Eg.,
>> > set AUDIODEV=plughw:CARD=ICH5,DEV=0; play m94.WAV
>> 
>> Hasty reply.  In further use, didn't always work.  I removed the PCI 
>> sound card, removed the plastic cover from the sockets on the system 
>> board and connected speakers.  Subsequently commands such as this 
>> always work.
>> 
>> set AUDIODEV=plughw:CARD=ICH5,DEV=0 ; play a42.WAV
>
>Are you in csh/tcsh?  If you're in a more "normal" shell (bash or zsh),
>that set command doesn't do anything useful.  Certainly nothing that
>would affect the play command.
>
>Even if you're in (t)csh, my understanding is that "set" sets shell
>variables, and you need "setenv" to set environment variables (which
>could conceivably affect the play command).  So, even in (t)csh, I
>don't see how your set command is supposed to work.
>
>Other shells... rc? fish?  I don't know these.  I have no idea what
>the set command does in them.
>

[toc] | [prev] | [next] | [standalone]

#240507

I've reordered this reply to get rid of top posting...

On Tue, 2021-09-28 at 17:38 +0000, Nils wrote:
> Am 28. September 2021 19:32:02 MESZ schrieb Greg Wooledge <
> greg@wooledge.org>:
> > On Tue, Sep 28, 2021 at 08:19:26AM -0700, peter@easthope.ca wrote:
> > > > CONCLUSIONS
> > > > 
> > > > Audio messages can be interpreted.  Eg.,
> > > > set AUDIODEV=plughw:CARD=ICH5,DEV=0; play m94.WAV
> > > 
> > > Hasty reply.  In further use, didn't always work.  I removed the PCI 
> > > sound card, removed the plastic cover from the sockets on the system 
> > > board and connected speakers.  Subsequently commands such as this 
> > > always work.
> > > 
> > > set AUDIODEV=plughw:CARD=ICH5,DEV=0 ; play a42.WAV
> > 
> > Are you in csh/tcsh?  If you're in a more "normal" shell (bash or zsh),
> > that set command doesn't do anything useful.  Certainly nothing that
> > would affect the play command.
> > 
> > Even if you're in (t)csh, my understanding is that "set" sets shell
> > variables, and you need "setenv" to set environment variables (which
> > could conceivably affect the play command).  So, even in (t)csh, I
> > don't see how your set command is supposed to work.
> > 
> > Other shells... rc? fish?  I don't know these.  I have no idea what
> > the set command does in them.
> > 
>
> I agree. In the "normal" shells, you need to use "export" instead of "set"!
>

Or, if you don't want to assign the variable value in the current shell
environment, just that of an external command you run, then you can
make the assignment part of the same command expression: 

  VAR=value command

Example in action...

$ FOO=foo
$ FOO=bar sh -c 'echo $FOO'
bar
# command above saw new value 'bar'
$ echo $FOO
foo
# this shell kept original value 'foo'

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#240518

    From: Greg Wooledge <greg@wooledge.org>
    Date: Tue, 28 Sep 2021 13:32:02 -0400
> Are you in csh/tcsh? 

I haven't set a shell.  According to https://wiki.debian.org/Shell 
it's bash.

> If you're in a more "normal" shell (bash or zsh),
> that set command doesn't do anything useful.  Certainly nothing that
> would affect the play command.

Now that there is only one internal sound device this seems right.
play a42.WAV

> ... "set" sets shell
> variables, and you need "setenv" to set environment variables (which
> could conceivably affect the play command). 

If the sound card is replaced, will try this sort of thing.
setenv AUDIODEV=plughw:CARD=ICH5,DEV=0 ; play a42.WAV

with present /dev/ names I guess something similar to this is out of 
the question.
sox a42.WAV /dev/snd/blaaaa

Device names are used for storage devices and for network adapters.  
Why not for sound devices?

I expected to find relevant examples in a manual page or wiki page.  No 
such luck. Sorry to repeat but documentation needs attention.

Thanks,                       ... P.

-- 
48.7693 N 123.3053 W
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140

[toc] | [prev] | [next] | [standalone]

#240519

On Tue, Sep 28, 2021 at 02:31:18PM -0700, peter@easthope.ca wrote:
>     From: Greg Wooledge <greg@wooledge.org>
>     Date: Tue, 28 Sep 2021 13:32:02 -0400
> > Are you in csh/tcsh? 
> 
> I haven't set a shell.  According to https://wiki.debian.org/Shell 
> it's bash.

Do not guess.  Do not assume defaults are in place.  Just find out.

ps -p $$

> If the sound card is replaced, will try this sort of thing.
> setenv AUDIODEV=plughw:CARD=ICH5,DEV=0 ; play a42.WAV

Now you're mixing tcsh and bash commands, and you're getting it wrong
for both shells.

If it turns out you're in bash, then what you want is:

export AUDIODEV=plughw:CARD=ICH5,DEV=0

[toc] | [prev] | [next] | [standalone]

#240538

[Multipart message — attachments visible in raw view] — view raw

On Tue, Sep 28, 2021 at 02:31:18PM -0700, peter@easthope.ca wrote:
>     From: Greg Wooledge <greg@wooledge.org>
>     Date: Tue, 28 Sep 2021 13:32:02 -0400
> > Are you in csh/tcsh? 
> 
> I haven't set a shell.  According to https://wiki.debian.org/Shell 
> it's bash.

It might be willing to tell you:

  echo $SHELL

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#240547

On Wed, 29 Sept 2021 at 16:57, <tomas@tuxteam.de> wrote:
> On Tue, Sep 28, 2021 at 02:31:18PM -0700, peter@easthope.ca wrote:

> > I haven't set a shell.  According to https://wiki.debian.org/Shell
> > it's bash.

> It might be willing to tell you:
>   echo $SHELL

I wouldn't give that advice, it's rather misleading. Demo:

[david@kablamm ~]$ echo $SHELL
/bin/bash
[david@kablamm ~]$ dash
$ echo $SHELL
/bin/bash
$

Why is it so? As per 'man 1 login', $SHELL contains the shell
you *want* when you login, not the shell you *have* :)

On Wed, 29 Sept 2021 at 08:12, Greg Wooledge <greg@wooledge.org> wrote:
> Do not guess.  Do not assume defaults are in place.  Just find out.
> ps -p $$

As usual, Greg's advice is worth following.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web