Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Hamish MB]

Hi Ralph,

Really interesting! It turns out I read the slow goodbye to C post 
before! I still like C++, but Python tends to be my goto language, 
partially because it's what I first learned in 2013, so I'm not quite 
proficient with it. I quite like Java too, which I've been studying in 
my Open University courses.

What languages do you like?

Hamish


On 14/04/18 18:02, Ralph Corderoy wrote:
> Hi Hamish,
>
> Clearing out old emails...
>
>> Why is it that you dislike C++ Ralph? I admit it is overcomplicated,
>> but I'm quite fond of it :)
> I lived through the flight of the `object-orientated programming' silver
> bullet, and it never had the scope it promised.  C++ jumped aboard early
> on, just as Stroustrup has had it encompass every passing shiny thing
> since whilst ignoring the complexity cost.
>
> This is old, but a reasonable summary.
> http://www.catb.org/esr/writings/taoup/html/ch14s04.html#cc_language
> The same author recently covered why C and not C++ again in
> http://esr.ibiblio.org/?p=7724 which I probably linked to on another
> thread in recent months.
>
> Cheers, Ralph.
>

-- 
Next meeting:  Bournemouth, Tuesday, 2018-05-01 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Hamish,

Clearing out old emails...

> Why is it that you dislike C++ Ralph? I admit it is overcomplicated,
> but I'm quite fond of it :)

I lived through the flight of the `object-orientated programming' silver
bullet, and it never had the scope it promised.  C++ jumped aboard early
on, just as Stroustrup has had it encompass every passing shiny thing
since whilst ignoring the complexity cost.

This is old, but a reasonable summary.
http://www.catb.org/esr/writings/taoup/html/ch14s04.html#cc_language
The same author recently covered why C and not C++ again in
http://esr.ibiblio.org/?p=7724 which I probably linked to on another
thread in recent months.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-05-01 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

> Yes it could be a leftover from the Python program.  At the moment the
> Python still runs on boot-up and then I kill it with Ctr-C.

If it's a zombie it's because its parent isn't reaping its death.  That
means it has a parent that's living, and that will tell you whether it's
the Python program or something you've manually started.  `ps l 42' will
give a long listing of PID 42, including PPID.

> I have realised that I can play the music files no matter where they
> are even though I'm using the same hw:2,0 port that has just failed
> with bells.  None of the bells files work with that or any other port,
> but I can't see what is wrong with the format of the files and they
> work if I send them to the bcm audio channel.

`ffmpeg -i foo.mp4 |& grep Audio:' can show detail about a file and may
highlight differences.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Saturday, 10 March 2018 14:33:46 GMT Terry Coles wrote:
> No all I have to do is work out why the bells won't play to the USB device,
> but will play to the bcm device.

I think I can use omxplayer for the bells, which works perfectly.  It's only 
the mp3 files that I need to loop continuously.

Thanks, Ralph for all your help again.

Hopefully, I won't need to come back again, but who knows :-)

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Saturday, 10 March 2018 15:28:53 GMT Ralph Corderoy wrote:
> Yes, but that means you've asked udev to assign an ID based on USB port,
> not whether you have substituted the `1' above with that ID when trying
> to play a tune.

I've solved this now; as mentioned in my other post.

The labels do work, but I have to use hw:label,device with mpg321.  aplay 
seemed OK with just the label, which is what threw me.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

> > > > Have you tried using the ID you've assigned with udev based on
> > > > the USB port as the card number;  the `1' in `1,0' above?
> > >
> > > I've tried allsorts
> > 
> > I can't tell if that includes my suggestion.  :-)
>
> Well I did say that I'd been using udev rules.

Yes, but that means you've asked udev to assign an ID based on USB port,
not whether you have substituted the `1' above with that ID when trying
to play a tune.

> As mentioned previously, labels only work with aplay and omxplayer,
> which don't support Python lists or looping through a list.

This might help.  Ignore aplay()'s definition;  it's just because I
don't have that command here.

$ aplay() { s=$((RANDOM % 3 + 1)); echo playing $1 for $s s; sleep $s; }
$
$ while :; do for f in zadok.mp3 black-dog.flac; do aplay $f; done; done
playing zadok.mp3 for 1 s
playing black-dog.flac for 3 s
playing zadok.mp3 for 1 s
playing black-dog.flac for 3 s
playing zadok.mp3 for 2 s
playing black-dog.flac for 1 s
playing zadok.mp3 for 3 s
^C
$

> It's easier to observe results and copy'n'paste from this machine than
> from the Pi.

But they don't have to behave the same, e.g. Raspbian probably thinks
any audio device belongs to the one logged-in user whereas your normal
distribution could be a lot more choosy because it knows there can be
multiple users and perhaps multiple heads.

Surely once you've ssh'd in from a terminal it all looks the same from
the cut and paste point of view?  :-)

> ATTRS{idVendor}=="8086", ATTRS{idProduct}=="0808", ATTR{id}="TOWER"
> ATTRS{idVendor}=="0d8c", ATTRS{idProduct}=="013c", ATTR{id}="CHANCEL"

Oh, you've different VID:PID now, I must have forgotten that.  I thought
you were going by USB port number, as explained on that page you linked
to.

> pcm.TOWER {
> type hw
> card 0
> device 0
> }

Is that trying to tell it to map 0,0 to your udev TOWER ID, or that a
thing called TOWER is to access 0,0 when used?

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Saturday, 10 March 2018 14:19:19 GMT Terry Coles wrote:
> On Saturday, 10 March 2018 14:08:41 GMT Ralph Corderoy wrote:
> > hw:label,device.  Are you only using the Pi for these trials, or

OK.  Just spotted it.  I wasn't using the device number with the label, so I 
was getting a 'Device not found' message.

No all I have to do is work out why the bells won't play to the USB device, 
but will play to the bcm device.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Saturday, 10 March 2018 14:08:41 GMT Ralph Corderoy wrote:
> I can't tell if that includes my suggestion.  :-)

Well I did say that I'd been using udev rules.

> Why would they?  I thought the udev rules were mapping from a USB port
> to a textual label.  You then ditch the hw:card,device number and use

As mentioned previously, labels only work with aplay and omxplayer, which 
don't support Python lists or looping through a list.
 
> hw:label,device.  Are you only using the Pi for these trials, or

I'm using both.  It's easier to observe results and copy'n'paste from this 
machine than from the Pi.

> switching away from Raspbian?  What's your udev look like after
> following that guide?

Raspbian is the goal.

Here is the contents of /etc/udev/rules.d/70-alsa-permanent.rules:

SUBSYSTEM!="sound", GOTO="my_usb_audio_end"
ACTION!="add", GOTO="my_usb_audio_end"

ATTRS{idVendor}=="8086", ATTRS{idProduct}=="0808", ATTR{id}="TOWER"
ATTRS{idVendor}=="0d8c", ATTRS{idProduct}=="013c", ATTR{id}="CHANCEL"

LABEL="my_usb_audio_end" 

I've tried making the ATTR{id}=0 or 1 and that makes no difference.

Here is the contents of /etc/asound.conf:

pcm.!default {
type hw
card 0
device 0
}

ctl.!default {
type hw
card 0
device 0
}

pcm.TOWER {
type hw
card 0
device 0
}

ctl.TOWER {
type hw
card 0
device 0
}

pcm.CHANCEL {
type hw
card 1
device 0
}

ctl.CHANCEL {
type hw
card 1
device 0
}

I've also tried naming the Cards instead of using numbers.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Saturday, 10 March 2018 14:04:13 GMT Ralph Corderoy wrote:
> Kill how?

Ctrl-C

> In the same manner?

Yes.

> How are you identifying it as a zombie?  What's the arguments for that
> process?  `ps ww 42' where 42 is its process ID shows them `weally
> wide'.  Does that tell you if it's the one that's also using hw:2,0?
> Could it be you've been running your Python program and that's an mpg321
> from a leftover Subprocess.Popen?

Top says it's a Zombie - it is marked z.

Yes it could be a leftover from the Python program.  At the moment the Python 
still runs on boot-up and then I kill it with Ctr-C.

However, there is more evidence now:

I have realised that I can play the music files no matter where they are even 
though I'm using the same hw:2,0 port that has just failed with bells.  None 
of the bells files work with that or any other port, but I can't see what is 
wrong with the format of the files and they work if I send them to the bcm 
audio channel.

I'm still investigating this.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

> > >   subprocess.Popen(mpg321 -l -m -a hw:1,0 Playlist)
> > 
> > Have you tried using the ID you've assigned with udev based on the
> > USB port as the card number;  the `1' in `1,0' above?
>
> I've tried allsorts

I can't tell if that includes my suggestion.  :-)

> and whatever happens the hw: numbers never seem to bear any relation
> to the ID's that i created in the udev rules.

Why would they?  I thought the udev rules were mapping from a USB port
to a textual label.  You then ditch the hw:card,device number and use
hw:label,device.  Are you only using the Pi for these trials, or
switching away from Raspbian?  What's your udev look like after
following that guide?

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

> Outside of my Python program

Good, it's a lot easier to experiment and observe directly at the
command line.

> I can cd to a Playlist directory and issue:
>
>   mpg321 -m -a hw:1,0 
>
> and it works, playing from the USB device designated CHANCEL. Staying
> in the same directory I kill playback of the above file

Kill how?

> and issue:
>
>   mpg321 -m -a hw:2,0 
>
> and it now plays from the USB device designated TOWER. If I then kill
> that playback

In the same manner?

> and move to the directory which contains the bells and issue:
>
>   mpg321 -m -a hw:2,0 
>
> The playback fails with the error:
>
>   can't open libao driver with device hw:0,0 (is device in use?)
>
> as mentioned previously. If I run top, a Zombie mpg321 process shows
> up.

How are you identifying it as a zombie?  What's the arguments for that
process?  `ps ww 42' where 42 is its process ID shows them `weally
wide'.  Does that tell you if it's the one that's also using hw:2,0?
Could it be you've been running your Python program and that's an mpg321
from a leftover Subprocess.Popen?

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Saturday, 10 March 2018 13:55:04 GMT Ralph Corderoy wrote:
> You *have* to use udev to map from USB port to an ID.
> Assuming assignment to cards is random, but with a strong bias or
> memory, i.e. can't be relied upon at all.

This behaviour occurs even though I am using the instructions to set the port 
to an ID using udev!  Things seem to have improved in this department since I 
moved my .asoundrc contents to /etc/asound.config, though I can't see why.  
(See my post at 11:41.)

I've just spotted something trying to replicate the problem on this machine.  
I get the following error from syslog whn I plug an adaptor in:

error opening ATTR{/sys/devices/pci:00/:00:1d.0/
usb2/2-1/2-1.7/2-1.7:1.0/sound/card1/pcmC1D0p/id} for writing: Permission 
denied

So maybe udev has changed (again) and yet another technique is required.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

> Having worked consistently for many reboots, I just got a couple of
> occasions when Card 0 came up as the bcm audio and the TOWER device
> got moved to Card 2.

You *have* to use udev to map from USB port to an ID.
Assuming assignment to cards is random, but with a strong bias or
memory, i.e. can't be relied upon at all.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

> I assume that this is because only one instance of the driver for the
> USB Audio devices is loaded at boot-up and that is in use because it
> is still playing the music.

That sounds wrong.  A driver is a piece of code that, given details
about a device and somewhere to store its own state about that device,
runs for multiple devices by being given a reference to the appropriate
lump of data for the `current' device each time it's asked to do
something.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Saturday, 10 March 2018 13:47:25 GMT Ralph Corderoy wrote:
> > subprocess.Popen(mpg321 -l -m -a hw:1,0 Playlist)
> 
> Have you tried using the ID you've assigned with udev based on the USB
> port as the card number;  the `1' in `1,0' above?

I've tried allsorts and whatever happens the hw: numbers never seem to bear 
any relation to the ID's that i created in the udev rules.

See my other post.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

> https://github.com/dh1tw/remoteAudio/wiki/Persistent-USB-Mapping-of-Audio-devices-%28Linux%29
>
> So I tried this, but hit another snag because although it worked, it
> solved the wrong problem. I found that it works well to provide an
> *identity* for the device, so I can tie a bus or Manufacturer's ID to
> a label, but not to a channel ID (ie hw:x,y).
...
>   subprocess.Popen(mpg321 -l -m -a hw:1,0 Playlist)

Have you tried using the ID you've assigned with udev based on the USB
port as the card number;  the `1' in `1,0' above?

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Friday, 9 March 2018 14:36:25 GMT Terry Coles wrote:
> The light at the end of the tunnel is rapidly vanishing.  Having worked
> consistently for many reboots, I just got a couple of occasions when Card 0
> came up as the bcm audio and the TOWER device got moved to Card 2.

I may have made some progress.  I've moved the contents of my .asoundrc file to 
/etc/
asound.conf and I /think/ that I've now got the TOWER and CHANCEL USB devices 
coming 
up as hw:2,0 and hw:1,0 respectively.  Time will tell if they stay there.

I may have made a little progress on the driver thing too, but I don't know 
what it all 
means.

What I am now seeing is somewhat weird. Outside of my Python program I can cd 
to a 
Playlist directory and issue:

mpg321 -m -a hw:1,0 

and it works, playing from the USB device designated CHANCEL. Staying in the 
same 
directory I kill playback of the above file and issue:

mpg321 -m -a hw:2,0 

and it now plays from the USB device designated TOWER. If I then kill that 
playback and 
move to the directory which contains the bells and issue:

  mpg321 -m -a hw:2,0 

The playback fails with the error:

can't open libao driver with device hw:0,0 (is device in use?)

as mentioned previously. If I run top, a Zombie mpg321 process shows up.  Any 
ideas as to 
what is going on?


-- 



Terry Coles
-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Friday, 9 March 2018 13:37:10 GMT Terry Coles wrote:
> The light at the end of the tunnel just got smaller.  The two USB Audio
> devices now seem to come up consistently on channels hw:0,0 and hw:0,1, but

The light at the end of the tunnel is rapidly vanishing.  Having worked 
consistently for many reboots, I just got a couple of occasions when Card 0 
came up as the bcm audio and the TOWER device got moved to Card 2.

So I seem to be back to square one, even when it works, I haven't got a driver 
and then it doesn't always work anyway

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Friday, 9 March 2018 13:09:37 GMT Terry Coles wrote:
> More testing needed, but I may be seeing the light at the end of the tunnel
> (everything crossed).

The light at the end of the tunnel just got smaller.  The two USB Audio 
devices now seem to come up consistently on channels hw:0,0 and hw:0,1, but I 
now get the error:

can't open libao driver with device hw:0,0

when the bells are required.  This is what happens:

At bootup, the program starts playing music to the device labelled CHANCEL 
using channel hw:0,1.  This works every time.  After 15 minutes or less, the 
program tries to send the chimes to the device labelled TOWER using channel 
hw:0,0.  That's when the error occurs.

I assume that this is because only one instance of the driver for the USB 
Audio devices is loaded at boot-up and that is in use because it is still 
playing the music.

Assuming that I'm right, how do I force the OS to load a second driver 
instance for the TOWER?

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Friday, 9 March 2018 10:57:36 GMT Terry Coles wrote:
> https://github.com/dh1tw/remoteAudio/wiki/Persistent-USB-Mapping-of-Audio-de
> vices-%28Linux%29
> 
> So I tried this, but hit another snag because although it worked, it solved
> the wrong problem. I found that it works well to provide an *identity* for
> the device, so I can tie a bus or Manufacturer's ID to a label, but not to
> a channel ID (ie hw:x,y).

I just spotted something that I'd missed.  The .asoundrc file in the Pi's home 
directory appears to be overwritten by Raspbian every now and then!!

Apparently, this occurs on reboot if the audio card selection is set to 'Auto' 
in raspi-config, so I've just set it to 'Force HDMI' and it has survived four 
reboots so far.

More testing needed, but I may be seeing the light at the end of the tunnel 
(everything crossed).

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Wednesday, 17 January 2018 23:06:44 GMT Ralph Corderoy wrote:
> There's also https://alsa.opensrc.org/MultipleUSBAudioDevices that
> describes the parameters the kernel module can take to index the audio
> interfaces, and https://alsa.opensrc.org/Udev that it links to at the
> end for using udev, especially the second section where he has five
> identical USB audio interfaces wired to distinct rooms.

I fixed the cross-talk and extraneous noise issue in hardware and had hoped to 
fix the 
hum, to avoid having to solve the USB problem, but the hum remained, so I 
returned to 
Ralph's suggestion.

Unfortunately, udev has changed a bit since that article was written and I 
found that with 
Rasbian Jessie (which we are using at the WMT for this project), the solution 
failed due to 
write permission problems.

I therefore posted again on the Raspberry Pi Forums and received this 
suggestion:

https://github.com/dh1tw/remoteAudio/wiki/Persistent-USB-Mapping-of-Audio-devices-%28Linux%29

So I tried this, but hit another snag because although it worked, it solved the 
wrong 
problem. I found that it works well to provide an *identity* for the device, so 
I can tie a 
bus or Manufacturer's ID to a label, but not to a channel ID (ie hw:x,y).

At first I thought that I could use omxplayer to play my tracks, (or aplay if I 
converted all 
the mp3 files to .wav (urrgh)). I got omxplayer to work reliably, but 
unfortunately it does 
not support the playing of a Python List containing all the files I want to 
play (eg a Playlist). 
It accepts the List, but only plays the first track before exiting, whereas I 
need the player to 
loop endlessly round a playlist until I stop it (by killing the mpg321's 
process). You may 
recall that I have been using mpg321 within Python as follows:

subprocess.Popen(mpg321 -l -m -a hw:1,0 Playlist)

Where Playlist is the list of files to be played. This was suggested a year or 
two back (by 
Ralph I think), because of Python's thread limit which won't allow me to play 
two tracks 
simultaneously (the bells and the music) and then use GPIO events to trap 
signals from 
physical switches (to stop playing or change the Playlist) and also to use GPIO 
to activate a 
couple of solenoids. By using subprocess.Popen in conjunction with mpg321 I can 
take 
advantage of OS multitasking instead of using Python control. 

Any suggestions of another solution (or a player that supports alsa labels and 
looping 
through a playlist)?  Or YAS  (Yet Another Solution)?

-- 



Terry Coles
-- 
Next meeting:  Bournemouth, Tuesday, 2018-04-03 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[PeterMerchant via dorset]

One favourite thing to apply the `right-left' rule to when explaining
this to people is the standard library's signal(3).  :-)

 void (*signal(int, void (*)(int)))(int);

Wow. This sort of thing does my head in. definitely not something for a 
cursory look at. You need to heave your head DEEP into the programming.  
It took me  a minute or two to determine that there are not too many 
right brackets on the second int.


I'm with Terry on the simple programming with 'c' experience.

Peter M.



--
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Tim,

> > > >   `const char *p' means p is a pointer to a char that's const.
>
> Although it's a bit ugly in this case, I prefer to write this as
>
> char const *p
>
> Then you can read right to left:
>
> p is a pointer to a const char.

That's true;  it saves the "that's" on each qualifier.  It seems the
other way has market share though, at least on the source I see.  Both
are legal, of course.

> uint8_t volatile * const tpmsc_rising

One favourite thing to apply the `right-left' rule to when explaining
this to people is the standard library's signal(3).  :-)

void (*signal(int, void (*)(int)))(int);

In Go, with its left-to-right reading, that's

func signal(sig int, handler func(int)) func(int) { ...

No `void' required there as functions return nothing unless explicitly
stated, e.g. `func foo() uint64 { ...'.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[tda]

Hi Ralph

On 22/01/18 14:04, Ralph Corderoy wrote:

Hi Terry,


  `const char *p' means p is a pointer to a char that's const.




Although it's a bit ugly in this case, I prefer to write this as

char const *p

Then you can read right to left:

p is a pointer to a const char.

This makes life easier when things get more involved. Working on a bunch 
of definitions at the moment which look like:


uint8_t volatile * const tpmsc_rising

i.e. tpmsc_rising is a constant pointer to a volatile uint8_t.

Cheers


Tim

--
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

> >  `const char *p' means p is a pointer to a char that's const.
> 
> What does that actually mean in terms of what it points at?  Obviously
> p cannot be a char because it is incremented and the pointer is
> containing a memory address, so what is char in this case?

You're right, p is a variable holding a memory address.  We've told the
compiler that the type of thing at that address is a char.  This affects
how that memory is read and written, e.g. how many bytes, and the amount
to adjust the memory address by when adding to the pointer.

Assuming 16-bit memory addresses, with memory laid out like this.

.p
9000  90
9001  10
...
.s
9010  66  'f'
9011  6f  'o'
9012  6f  'o'
9013  00  '\0'

char can be assumed to be the same as byte.  (Whether it's a signed or
unsigned integer is implementation defined, i.e. the compiler's choice.)
Pointer p holds the address that's the first byte of NUL-terminated
string s, 0x9010.

If p isn't a const pointer then it can be adjusted, e.g. `p += 2', and
would be incremented by two times the size of the thing it points to,
here a char so 1.  p becomes 0x9012, pointing at the second `o', with
`p[-2]' being the `f'.

If p isn't a pointer to a const then the thing it points to can be
adjusted, e.g. «*p = 'b'» turns the C string into "boo".  `p[2]--' would
then make it "bon".  If it is a pointer to a thing that's const then
that thing can't be adjusted *through this pointer*.

But if s was declared as non-const then its memory can be altered.  Not
through a p that's a pointer to a const char, because the compiler stops
that, but `char *q = (char *)p' casts away the const and then `(*q)++'
would turn "bon" into "con".

Things declared const may be located in ROM by the compiler so a
hardware error may occur on attempts to write to the address, assuming
the instruction set has that ability.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Monday, 22 January 2018 13:21:42 GMT Terry Coles wrote:
> Thinking about what you said about this usage:
> >  `const char *p' means p is a pointer to a char that's const.

Rereading your original post, I think I've now caught on.

> What does that actually mean in terms of what it points at?
> 
> Obviously p cannot be a char because it is incremented and the pointer is
> containing a memory address, so what is char in this case?


-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Monday, 22 January 2018 12:38:33 GMT Ralph Corderoy wrote:
> `const' didn't exist when I started C, probably not for you either.  It
> isn't in K  It was added by the X3J11 committee as part of ANSI
> standardisation that became C89, AKA C90.  K has it.

Yes.  I started with plain ol' K, in 1990.

> A lot of the time it gets in the way because a function doesn't bother
> to state a parameter's const-ness and you have to toss the passed
> value's const away with a cast on the call.  I suspect it was added more
> as a compiler hint than improving software quality, like the committee's
> `volatile', and aborted `noalias' suggestions.

Thinking about what you said about this usage:

>  `const char *p' means p is a pointer to a char that's const.

What does that actually mean in terms of what it points at?

Obviously p cannot be a char because it is incremented and the pointer is 
containing a memory address, so what is char in this case?

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

> I did say my knowledge of C / C++ is 'Janet and John', but I suspect
> that I never even made that grade !

`const' didn't exist when I started C, probably not for you either.  It
isn't in K  It was added by the X3J11 committee as part of ANSI
standardisation that became C89, AKA C90.  K has it.

A lot of the time it gets in the way because a function doesn't bother
to state a parameter's const-ness and you have to toss the passed
value's const away with a cast on the call.  I suspect it was added more
as a compiler hint than improving software quality, like the committee's
`volatile', and aborted `noalias' suggestions.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Monday, 22 January 2018 12:14:21 GMT Ralph Corderoy wrote:
> > I didn't spot this yesterday, but that won't work because p is used as
> > a variable within that function.
> 
> Have you tried it?  :-)
> 
> int GetDValue(const char *k)
> {
> char *p = strrchr((char *)k, 'D');
> ...
> p++;
> 
> Yes, I read that before making the suggestion.
> `const char *p' means p is a pointer to a char that's const.
> It doesn't mean it's a const pointer to a char that can vary,
> nor that it's a const pointer to a const char.
> The pointer and char can be const or not, giving four variations.
> Thus the `p++' should be fine;  it's moving the pointer onto the next
> const char.

Right thanks.  I did say my knowledge of C / C++ is 'Janet and John', but I 
suspect that I never even made that grade !

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

> > Looking at the use of `p', I suggest making that a const too.
>
> I didn't spot this yesterday, but that won't work because p is used as
> a variable within that function.

Have you tried it?  :-)

int GetDValue(const char *k) 
{
char *p = strrchr((char *)k, 'D');
...
p++;

Yes, I read that before making the suggestion.
`const char *p' means p is a pointer to a char that's const.
It doesn't mean it's a const pointer to a char that can vary,
nor that it's a const pointer to a const char.
The pointer and char can be const or not, giving four variations.
Thus the `p++' should be fine;  it's moving the pointer onto the next
const char.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Sunday, 21 January 2018 16:23:56 GMT Ralph Corderoy wrote:
> `k' is already a `const char *' so the cast to the same thing looks
> redundant.  Because that parameter is a const, I think the first version
> is picked, it returns a `const char *', but it's being assigned to `p'
> that's a non-const `char *'.
> 
> Looking at the use of `p', I suggest making that a const too.

I didn't spot this yesterday, but that won't work because p is used as a 
variable within that function.  Here is the full code:

//Retrieve the subdevice value, whith comes after the capital D
//in the device name, (i.e. pcmC0D1).
int GetDValue(const char *k) 
{
char *p = strrchr((char *)k, 'D');
if (!p) {
return -1;
}
p++;
int d = strtol(p, NULL, 0);
if (d < 0 || d > 32)
return 0;

return d;
}

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Hamish MB]

I think Ralph's solution is the better on if it works - instead of removing 
const from that cast, declare the variable as const.

Why is it that you dislike C++ Ralph? I admit it is overcomplicated, but I'm 
quite fond of it :)

Hamish
On 21 Jan 2018, at 16:30, Terry Coles 
> wrote:

On Sunday, 21 January 2018 16:23:56 GMT Ralph Corderoy wrote:
 I haven't time to reply to your original email at the moment, though
 from a quick skim the use of a compiled language looks like overkill,
 and tedious due to low-level parsing.

Ralph,

No rush, but would you use something like the Perl example at the beginning of
that page?
-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Sunday, 21 January 2018 16:23:56 GMT Ralph Corderoy wrote:
> I haven't time to reply to your original email at the moment, though
> from a quick skim the use of a compiled language looks like overkill,
> and tedious due to low-level parsing.

Ralph,

No rush, but would you use something like the Perl example at the beginning of 
that page?

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

I haven't time to reply to your original email at the moment, though
from a quick skim the use of a compiled language looks like overkill,
and tedious due to low-level parsing.

> $ g++ USB_Audio_Fix.cpp -o alsa_name
> USB_Audio_Fix.cpp: In function ‘int GetDValue(const char*)’:
> USB_Audio_Fix.cpp:112:22: error: invalid conversion from ‘const char*’ to 
> ‘char*’ [-fpermissive]
>  char *p = strrchr((const char *)k, 'D');
>~~~^~

(I studiously avoid C++.  It's a terrible language, steadily getting
worse.)  There are two definitions of strrchr().

const char *strrchr(const char *s, int c);
char *strrchr(char *s, int c);

`k' is already a `const char *' so the cast to the same thing looks
redundant.  Because that parameter is a const, I think the first version
is picked, it returns a `const char *', but it's being assigned to `p'
that's a non-const `char *'.

Looking at the use of `p', I suggest making that a const too.

As for how it compiled for the author;  compilers often change and
failure to compile old source if it doesn't meet the new higher bar.
That's why big projects archive everything from the firmware upwards.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Sunday, 21 January 2018 16:02:03 GMT Hamish MB wrote:
> Yes, it seems to me that this code has a mistake in it. The fix doesn't
> change how the code works, just fixes (assuming this was indeed a mistake)
> that cast, which seems like something that could never work to me.
 
Well.  I made the change and I now have an executable.  It still worries me a 
bit though.

I probably won't have time to check it out properly for a few more days now, 
dues to other commitments.

> As far as I can see, that's an error in the code, because it tried to do
> something that isn't allowed. You could also try using the -fpermissive
> flag by the looks of it.

I did and it didn't help.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Hamish MB]

Hi,

Yes, it seems to me that this code has a mistake in it. The fix doesn't change 
how the code works, just fixes (assuming this was indeed a mistake) that cast, 
which seems like something that could never work to me.

As far as I can see, that's an error in the code, because it tried to do 
something that isn't allowed. You could also try using the -fpermissive flag by 
the looks of it.

Hamish
On 21 Jan 2018, at 15:41, Terry Coles 
> wrote:

On Sunday, 21 January 2018 15:31:15 GMT Hamish MB wrote:
 Try removing the "const" from the cast for the variable k, so it instead
 reads:

 char *p = strrchr((char *)k, 'D');

So you are suggesting that the code on the website where I got this from is in
error?  If so, I wonder how he got it to work.

 This may or may not fix the problem depending on how the rest of the code
 works. You can't cast a const type variable to a non-const type because it
 would potentially have massive security implications - eg people modifying
 passwords on their way to being stored / vice versa man in the middle type
 attacks.

Well.  That's one of the things that worries me.  If this fix changes the
functionality of the code from what the original author intended, then my USB
devices won't be permanently given Card Nos and I'll be chasing rainbows.

 What compiler are you using by the way?

Unless Kubuntu points at something different the GNU C++ compiler; that's
what's installed.
-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Sunday, 21 January 2018 15:31:15 GMT Hamish MB wrote:
> Try removing the "const" from the cast for the variable k, so it instead
> reads:
 
> char *p = strrchr((char *)k, 'D');

So you are suggesting that the code on the website where I got this from is in 
error?  If so, I wonder how he got it to work.

> This may or may not fix the problem depending on how the rest of the code
> works. You can't cast a const type variable to a non-const type because it
> would potentially have massive security implications - eg people modifying
> passwords on their way to being stored / vice versa man in the middle type
> attacks.
 
Well.  That's one of the things that worries me.  If this fix changes the 
functionality of the code from what the original author intended, then my USB 
devices won't be permanently given Card Nos and I'll be chasing rainbows.

> What compiler are you using by the way?

Unless Kubuntu points at something different the GNU C++ compiler; that's 
what's installed.  

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Hamish MB]

Hi,

Try removing the "const" from the cast for the variable k, so it instead reads:

char *p = strrchr((char *)k, 'D');

This may or may not fix the problem depending on how the rest of the code 
works. You can't cast a const type variable to a non-const type because it 
would potentially have massive security implications - eg people modifying 
passwords on their way to being stored / vice versa man in the middle type 
attacks.

What compiler are you using by the way?

Hamish
On 21 Jan 2018, at 15:25, Terry Coles 
> wrote:

On Sunday, 21 January 2018 12:35:16 GMT Terry Coles wrote:
 I'm starting to get my head round this and think that I have a fighting
 chance of sorting it out.  However, I have a couple of queries (so far),
 both coming from the C++ code in your second link.

I'm having problems compiling the C++ code.  (Mainly because when I wrote C 
(about 35
years ago), I was at Janet and John level and the little I did with C++ was 
even less.)   This
line:

char *p = strrchr((const char *)k, 'D');

gives the following error:

terry@OptiPlex:~/Development/Wimborne_Model_Town/Winter_2016-17_Projects/
Minster_Bells/Code/USB_Audio_Fix$ g++ USB_Audio_Fix.cpp -o alsa_name
USB_Audio_Fix.cpp: In function ‘int GetDValue(const char*)’:
USB_Audio_Fix.cpp:112:22: error: invalid conversion from ‘const char*’ to 
‘char*’ [-
fpermissive]
 char *p = strrchr((const char *)k, 'D');
   ~~~^~

I can see what the error is saying but not why you can't do this conversion.  
Can I anyone
shed any light?  I had assumed that the code would compile, but not for me it 
doesn't ;-(
-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Sunday, 21 January 2018 12:35:16 GMT Terry Coles wrote:
> I'm starting to get my head round this and think that I have a fighting
> chance of sorting it out.  However, I have a couple of queries (so far),
> both coming from the C++ code in your second link.

I'm having problems compiling the C++ code.  (Mainly because when I wrote C 
(about 35 
years ago), I was at Janet and John level and the little I did with C++ was 
even less.)   This 
line:

char *p = strrchr((const char *)k, 'D');

gives the following error:

terry@OptiPlex:~/Development/Wimborne_Model_Town/Winter_2016-17_Projects/
Minster_Bells/Code/USB_Audio_Fix$ g++ USB_Audio_Fix.cpp -o alsa_name
USB_Audio_Fix.cpp: In function ‘int GetDValue(const char*)’:
USB_Audio_Fix.cpp:112:22: error: invalid conversion from ‘const char*’ to 
‘char*’ [-
fpermissive]
 char *p = strrchr((const char *)k, 'D');
   ~~~^~

I can see what the error is saying but not why you can't do this conversion.  
Can I anyone 
shed any light?  I had assumed that the code would compile, but not for me it 
doesn't ;-(

-- 



Terry Coles
-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Wednesday, 17 January 2018 23:06:44 GMT Ralph Corderoy wrote:
> There's also https://alsa.opensrc.org/MultipleUSBAudioDevices that
> describes the parameters the kernel module can take to index the audio
> interfaces, and https://alsa.opensrc.org/Udev that it links to at the
> end for using udev, especially the second section where he has five
> identical USB audio interfaces wired to distinct rooms.

Ralph,

I'm starting to get my head round this and think that I have a fighting chance 
of sorting it out.  However, I have a couple of queries (so far), both coming 
from the C++ code in your second link.

1.  In the first major comment block, the author says that he made the 
following:  File: /etc/udev/rules.d/39-usb-alsa.rules.

Why 39-usb-... and not just usb-... ?

2.  Is there any reason why the author used C++ rather than C for this 
application?  Just personal preference or is there some benefit in this case?

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Wednesday, 17 January 2018 23:06:44 GMT Ralph Corderoy wrote:
> There's also https://alsa.opensrc.org/MultipleUSBAudioDevices that
> describes the parameters the kernel module can take to index the audio
> interfaces, and https://alsa.opensrc.org/Udev that it links to at the
> end for using udev, especially the second section where he has five
> identical USB audio interfaces wired to distinct rooms.

That will be useful.

Looking again at my link to the post by William, noticed in my follow-up 
replies that I had 
been struggling a bit with the udev solution too.

I then looked at the discussions that went on after that time and remembered 
that I had 
originally been using a Pi Zero and a 'Naked' USB Hub from ModMyPi and had 
discovered, 
through this list, that the Zero has a Single-TT USB port and that had been at 
the root of 
the problem.

I then switched to using a Pi 3, which has a Multi-TT USB port.  The Pi 3 has 
an audio 
output, the whole problem of using multiple USB Audio Adaptors went away.

The rest is history  (well so was that really :-) )

> In USB terms, they're the Vendor and Product IDs, both 16-bit.  8086 is
> Intel's.  :-)  http://www.linux-usb.org/usb-ids.html doesn't know
> Intel's 0808 and that's why lsusb(8) isn't saying anything more than
> `Intel Corp.'.  That site accepts patches.

Yes.  I've always understood that, but since lsusb provided these numbers, I've 
always 
believed (until now) that they could be used to identify which interface 
carried the Audio 
device for the Bells and which for the music.

-- 



Terry Coles
-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

> What I did find was this:
>
> https://mailman.lug.org.uk/mailman/private/dorset/2016-December/015967.html

There's also https://alsa.opensrc.org/MultipleUSBAudioDevices that
describes the parameters the kernel module can take to index the audio
interfaces, and https://alsa.opensrc.org/Udev that it links to at the
end for using udev, especially the second section where he has five
identical USB audio interfaces wired to distinct rooms.

> > It's not the `0d8c:013c' or `8086:0808'.
>
> Those numbers are the Manufacturer's ID.

In USB terms, they're the Vendor and Product IDs, both 16-bit.  8086 is
Intel's.  :-)  http://www.linux-usb.org/usb-ids.html doesn't know
Intel's 0808 and that's why lsusb(8) isn't saying anything more than
`Intel Corp.'.  That site accepts patches.

The CM108 datasheet says it can have a 93C46 EEPROM attached that
contains the serial number, amongst other things, and it can then be
written using USB HID according to the datasheet from
https://www.cmedia.com.tw/support/download_center/39
I expect it's normally ommitted for cost.  :-)

> I also tried `dmesg | tail' and that wasn't much use either.

No, that's right.  You have to search for likely things and then read
the context either side.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2018-02-06 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Wednesday, 17 January 2018 17:04:56 GMT Ralph Corderoy wrote:
> I've been struggling to find this in the archives.  Even assuming 2016.
> https://mailman.lug.org.uk/mailman/private/dorset/
> https://www.mail-archive.com/dorset@mailman.lug.org.uk/
> 
> > At the time it was suggested that I could discriminate between the two
> > adaptors by reading their ID string.

I thought that it was William Sowerbutts that said it, but I couldn't find that 
either.  What I did find was this:

https://mailman.lug.org.uk/mailman/private/dorset/2016-December/015967.html

Which might be the answer.  I'll not be able to follow this up for a day or 
two, because of family illness and other commitments, but I'll have a look at 
the OMG! Ubuntu link and see if I can make it work.
 
> How are you observing the ID string?  I think you might be wrongly
> calling something else that.  It's not the `0d8c:013c' or `8086:0808'.

Those numbers are the Manufacturer's ID.  I'm sure that someone thought that 
these could be used; maybe it was simply said at a Meeting.

I've been getting those numbers from lsusb.

> BTW, when you did `dmesg | grep PnP' you may have discarded useful
> information in the vicinity of `PnP' lines that didn't contain that
> text, so it could be worth looking again.

I also tried `dmesg | tail' and that wasn't much use either.

> Also, `udevadm info -e' may give interesting details to distinguish the
> two, but you'd have to search through the output for `audio' and poke
> about.

Yes that was what William was referring to in his post.

> You've had this before.  I thought then you were sending a HTML email
> and Mailman was stripping it back to plain text, losing a lot of the
> content, and suggested you ensure you're sending plain text instead.  If
> that can't be done, put the text in a file and paste the output of
> `base64 

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Ralph Corderoy]

Hi Terry,

(Been offline.)

> You may remember my queries in November of last year regarding the use
> of two USB Audio Adaptors with a Raspberry Pi

I've been struggling to find this in the archives.  Even assuming 2016.
https://mailman.lug.org.uk/mailman/private/dorset/
https://www.mail-archive.com/dorset@mailman.lug.org.uk/

> At the time it was suggested that I could discriminate between the two
> adaptors by reading their ID string.

I recall, but would like to find that again in case there was other
useful bits.  :-)

> I managed to obtain a couple of USB Audio Adaptors with a different ID
> string

How are you observing the ID string?  I think you might be wrongly
calling something else that.  It's not the `0d8c:013c' or `8086:0808'.

BTW, when you did `dmesg | grep PnP' you may have discarded useful
information in the vicinity of `PnP' lines that didn't contain that
text, so it could be worth looking again.

Also, `udevadm info -e' may give interesting details to distinguish the
two, but you'd have to search through the output for `audio' and poke
about.

> This is weird, I think something is cutting off the information that I
> have been putting at the end of the message.  One more time:

You've had this before.  I thought then you were sending a HTML email
and Mailman was stripping it back to plain text, losing a lot of the
content, and suggested you ensure you're sending plain text instead.  If
that can't be done, put the text in a file and paste the output of
`base64 

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Hamish MB]

Potential solution:

If both speakers are in roughly the same place, does it matter which one each 
sound is played through? You could just play music though one of them, and do 
the bells with whichever speaker isn't already in use.

Hamish
On 14 Jan 2018, at 18:07, Hamish MB 
> wrote:
Weird that it keeps cutting it off!

I've been having email problems with this mailing list too - I've tried to 
reply to people a few times but it doesn't seem to work.

This is sent directly to you as well as the list Terry, so please let me know 
if you get this message twice :)

Hamish
On 14 Jan 2018, at 18:05, Terry Coles < 
d-...@hadrian-way.co.uk> wrote:

On Sunday, 14 January 2018 18:02:40 GMT you wrote:



 On Sunday, 14 January 2018 17:57:26 GMT Terry Coles wrote:

 Some stuff:



 This is weird, I think something is cutting off the information that I have

 been putting at the end of the message.  One more time:




I'll post it on the Raspberry Pi Forum later; have to go to dinner now.
-- 
Next meeting:  Bournemouth, Tuesday, 2018-01-09 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Sunday, 14 January 2018 18:03:56 GMT you wrote:
> I'll post it on the Raspberry Pi Forum later; have to go to dinner now.

Done.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-01-09 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Hamish MB]

Weird that it keeps cutting it off!

I've been having email problems with this mailing list too - I've tried to 
reply to people a few times but it doesn't seem to work.

This is sent directly to you as well as the list Terry, so please let me know 
if you get this message twice :)

Hamish
On 14 Jan 2018, at 18:05, Terry Coles 
> wrote:

On Sunday, 14 January 2018 18:02:40 GMT you wrote:
 On Sunday, 14 January 2018 17:57:26 GMT Terry Coles wrote:
 Some stuff:

 This is weird, I think something is cutting off the information that I have
 been putting at the end of the message.  One more time:

I'll post it on the Raspberry Pi Forum later; have to go to dinner now.
-- 
Next meeting:  Bournemouth, Tuesday, 2018-01-09 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Sunday, 14 January 2018 18:02:40 GMT you wrote:
> On Sunday, 14 January 2018 17:57:26 GMT Terry Coles wrote:
> Some stuff:
> 
> This is weird, I think something is cutting off the information that I have
> been putting at the end of the message.  One more time:

I'll post it on the Raspberry Pi Forum later; have to go to dinner now.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-01-09 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Sunday, 14 January 2018 17:57:26 GMT Terry Coles wrote:
Some stuff:

This is weird, I think something is cutting off the information that I have 
been 
putting at the end of the message.  One more time:

*terry@OptiPlex*:*~*$ aplay -l 


-- 



Terry Coles
-- 
Next meeting:  Bournemouth, Tuesday, 2018-01-09 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Sunday, 14 January 2018 17:51:51 GMT Terry Coles wrote:
> On Sunday, 14 January 2018 17:40:14 GMT Andrew wrote:
> > The IDs in lsusb won't help, they are the vendor ID and device ID for
> > that type of card, not that instance in your machine.
> 
> They would if I could tie the ID to the hw: channel in aplay, because I know
> which ID is plugged into the tower and which into the nave.
> 
> That's what I've been unable to do.
> 
> > It looks like aplay -D can use the whole device string, eg.
> > "plughw:CARD=Device,DEV=0" but mpg123 can't...
> > 
> > I've done some more experimenting and I can see how to do it... I think...
> > First list devices with 'aplay -l' (lowercase). On here I get this:
> > 
> > card 0: PCH [HDA Intel PCH], device 0: ALC887-VD Analog [ALC887-VD Analog]
> > 
> >Subdevices: 1/1
> >Subdevice #0: subdevice #0
> > 
> > card 1: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
> > 
> >Subdevices: 1/1
> >Subdevice #0: subdevice #0
> > 
> > card 2: Device [USB Sound Device], device 0: USB Audio [USB Audio]
> > 
> >Subdevices: 1/1
> >Subdevice #0: subdevice #0
> > 
> > There's three cards here, and each has one device.
> > The middle one (HDMI), is card 1, device 3. I can play through that with:
> > mpg123 -o alsa -a hw:1,3 /path/to/audio
> > 
> > Or if I want the USB device:
> > mpg123 -o alsa -a hw:2,0 /path/to/audio
> > 
> > If I wanted the internal card that would be hw:0,0, but there's nothing
> > plugged in to it right now... :)
> 
> Yes.  I understand that.  I posted my version of aplay -l at the Raspberry
> Pi Forum, but here it is again:
> 
> terry@OptiPlex:~$ aplay -l
>  List of PLAYBACK Hardware Devices 
> card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
>   Subdevices: 0/1
>   Subdevice #0: subdevice #0
> card 2: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 2: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 3: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 4: Device_1 [USB PnP Sound Device], device 0: USB Audio [USB Audio]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> 
> and here is what I got just now, with the same adaptors plugged into the
> same USB ports:
> 
> *terry@OptiPlex*:*~*$ aplay -l
Oops the thing didn't go through properly.  Here is the latest one again.

*terry@OptiPlex*:*~*$ aplay -l 


-- 



Terry Coles
-- 
Next meeting:  Bournemouth, Tuesday, 2018-01-09 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Sunday, 14 January 2018 17:40:14 GMT Andrew wrote:
> The IDs in lsusb won't help, they are the vendor ID and device ID for
> that type of card, not that instance in your machine.

They would if I could tie the ID to the hw: channel in aplay, because I know 
which ID is 
plugged into the tower and which into the nave.

That's what I've been unable to do.

> It looks like aplay -D can use the whole device string, eg.
> "plughw:CARD=Device,DEV=0" but mpg123 can't...
> 
> I've done some more experimenting and I can see how to do it... I think...
> First list devices with 'aplay -l' (lowercase). On here I get this:
> 
> card 0: PCH [HDA Intel PCH], device 0: ALC887-VD Analog [ALC887-VD Analog]
>Subdevices: 1/1
>Subdevice #0: subdevice #0
> card 1: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
>Subdevices: 1/1
>Subdevice #0: subdevice #0
> card 2: Device [USB Sound Device], device 0: USB Audio [USB Audio]
>Subdevices: 1/1
>Subdevice #0: subdevice #0
> 
> There's three cards here, and each has one device.
> The middle one (HDMI), is card 1, device 3. I can play through that with:
> mpg123 -o alsa -a hw:1,3 /path/to/audio
> 
> Or if I want the USB device:
> mpg123 -o alsa -a hw:2,0 /path/to/audio
> 
> If I wanted the internal card that would be hw:0,0, but there's nothing
> plugged in to it right now... :)

Yes.  I understand that.  I posted my version of aplay -l at the Raspberry Pi 
Forum, but here 
it is again:

terry@OptiPlex:~$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 2: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 3: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
   
card 4: Device_1 [USB PnP Sound Device], device 0: USB Audio [USB Audio]
   
  Subdevices: 1/1   
   
  Subdevice #0: subdevice #0

and here is what I got just now, with the same adaptors plugged into the same 
USB ports:

*terry@OptiPlex*:*~*$ aplay -l 


That's my problem.


-- 



Terry Coles
-- 
Next meeting:  Bournemouth, Tuesday, 2018-01-09 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Andrew]

I've just re-read your forum post and can see your output of 'aplay -l'.

So you have:
Internal (I guess it's internal):
hw:0,0
HDMI 0:
hw:2,3
HDMI 1:
hw:2,7
USB:
hw:3,0
USB:
hw:4,0

It would be nice if the output of aplay -l actually showed these rather 
than having the know how to put them together!
I believe it's possible to specify the subdevice with another comma, if 
needed.


--

Andrew.


--
Next meeting:  Bournemouth, Tuesday, 2018-01-09 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Andrew]

On 14/01/18 17:13, Terry Coles wrote:
I have used both aplay -l and aplay -L, but neither help. Here is a 
couple of

segments from the relevant output for the two devices:



sysdefault:CARD=Device
 USB PnP Sound Device, USB Audio
 Default Audio Device

..

plughw:CARD=Device,DEV=0
 USB PnP Sound Device, USB Audio
 Hardware device with all software conversions


sysdefault:CARD=Device_1
 USB PnP Sound Device, USB Audio
 Default Audio Device
front:CARD=Device_1,DEV=0



plughw:CARD=Device_1,DEV=0
 USB PnP Sound Device, USB Audio
 Hardware device with all software conversions


As you can see, the only difference between the two entries is the _1 after
Card=Device.  That doesn't tie up with the ID Numbers in lsusb either.

Of course, if I knew the name of the device that was connected to the channel
that I wanted, then aplay -D might be useful.  :-)



The IDs in lsusb won't help, they are the vendor ID and device ID for 
that type of card, not that instance in your machine.


It looks like aplay -D can use the whole device string, eg. 
"plughw:CARD=Device,DEV=0" but mpg123 can't...


I've done some more experimenting and I can see how to do it... I think...
First list devices with 'aplay -l' (lowercase). On here I get this:

card 0: PCH [HDA Intel PCH], device 0: ALC887-VD Analog [ALC887-VD Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: Device [USB Sound Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

There's three cards here, and each has one device.
The middle one (HDMI), is card 1, device 3. I can play through that with:
mpg123 -o alsa -a hw:1,3 /path/to/audio

Or if I want the USB device:
mpg123 -o alsa -a hw:2,0 /path/to/audio

If I wanted the internal card that would be hw:0,0, but there's nothing 
plugged in to it right now... :)


--

Andrew.


--
Next meeting:  Bournemouth, Tuesday, 2018-01-09 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

On Sunday, 14 January 2018 16:49:17 GMT Andrew wrote:
> Ideally you want a balanced audio output. I would give you a link to the
> USB to XLR audio device I bought many years ago, but I can't seem to
> find them any more! There's lots around with a single input but the one
> I got has two inputs and two outputs.
> There is this for the Raspberry Pi, however I'm not sure if you can have
> more than one on the same machine:
> 
> https://www.hifiberry.com/shop/boards/hifiberry-dac-pro-xlr/
> 
> Then you'd need a balanced amplifier and cables, and that should get rid
> of any hum at all.

We looked at these devices before we went with the solution that we chose.  
The problem is that they cost significantly more than the Raspberry Pi itself 
and an order of magnitude more than the USB Audio Adaptors.  Also, we're not 
looking for HiFi, just a reasonable rendition of organ music and bells.

I haven't given up with the hum problem, but the two USB adaptors solve the 
problem perfectly; as long as someone is there to iteratively discover which 
adaptor has been attached to which channel.  Not a practical proposition of 
course in a system runs 24/7 and has to cope with the odd power cut.

> I think you want 'aplay -L', not 'aplay -l'. Then you'll see the device
> names, something like "plughw:CARD=Device,DEV=0".
> 
>  From the man page:
> 
> -l, --list-devices
>List all soundcards and digital audio devices
> 
> -L, --list-pcms
>List all PCMs defined
> 
> -D, --device=NAME
>Select PCM by name

I have used both aplay -l and aplay -L, but neither help.  Here is a couple of 
segments from the relevant output for the two devices:



sysdefault:CARD=Device
USB PnP Sound Device, USB Audio
Default Audio Device

..

plughw:CARD=Device,DEV=0
USB PnP Sound Device, USB Audio
Hardware device with all software conversions


sysdefault:CARD=Device_1
USB PnP Sound Device, USB Audio
Default Audio Device
front:CARD=Device_1,DEV=0



plughw:CARD=Device_1,DEV=0
USB PnP Sound Device, USB Audio
Hardware device with all software conversions


As you can see, the only difference between the two entries is the _1 after 
Card=Device.  That doesn't tie up with the ID Numbers in lsusb either. 

Of course, if I knew the name of the device that was connected to the channel 
that I wanted, then aplay -D might be useful.  :-)

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2018-01-09 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Andrew]

Hi Terry,

On 14/01/18 11:27, Terry Coles wrote:

Everything in the garden was lovely until the 12 V (Audio Amp) PSU Brick failed 
in August
and the replacement turned out to be noisy.  There was always a bit of a hum 
loop, but it
was acceptable until the extra noisy PSU came along.


Ideally you want a balanced audio output. I would give you a link to the 
USB to XLR audio device I bought many years ago, but I can't seem to 
find them any more! There's lots around with a single input but the one 
I got has two inputs and two outputs.
There is this for the Raspberry Pi, however I'm not sure if you can have 
more than one on the same machine:


https://www.hifiberry.com/shop/boards/hifiberry-dac-pro-xlr/

Then you'd need a balanced amplifier and cables, and that should get rid 
of any hum at all.



I managed to obtain a couple of USB Audio Adaptors with a different ID string 
to the
original ones, so I thought that we could revert to plan A.  However, I can't 
work out how
to identify the channel from the info available from lsusb, aplay -l and dmesg.
I think you want 'aplay -L', not 'aplay -l'. Then you'll see the device 
names, something like "plughw:CARD=Device,DEV=0".


From the man page:

   -l, --list-devices
  List all soundcards and digital audio devices

   -L, --list-pcms
  List all PCMs defined

   -D, --device=NAME
  Select PCM by name

--

Andrew.


--
Next meeting:  Bournemouth, Tuesday, 2018-01-09 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

[Dorset] Using Two USB Audio Adaptors and Selecting the Right One Programatically

[Terry Coles]

Hi,

You may remember my queries in November of last year regarding the use of two 
USB 
Audio Adaptors with a Raspberry Pi; one to play the chimes and one to play the 
organ 
music inside the Wimborne Model Town Minster.  At the time it was suggested 
that I could 
discriminate between the two adaptors by reading their ID string.

In the event that solution didn't work for two reasons: first the USB Hub in a 
Pi Zero is a 
single-TT port and the other is because the two adaptors had the same ID string 
;-(

At the time we solved this by changing to a Pi 3 which has a (crude) audio jack 
so I could 
send the bells to that channel and the music to a USB Audio Adaptor plugged 
into one of 
the four available USB Ports.  (BTW, the Pi 3 has a multi-TT port).

Everything in the garden was lovely until the 12 V (Audio Amp) PSU Brick failed 
in August 
and the replacement turned out to be noisy.  There was always a bit of a hum 
loop, but it 
was acceptable until the extra noisy PSU came along.

I managed to obtain a couple of USB Audio Adaptors with a different ID string 
to the 
original ones, so I thought that we could revert to plan A.  However, I can't 
work out how 
to identify the channel from the info available from lsusb, aplay -l and dmesg.

I've published the question on the Raspberry Pi Forums at:

https://www.raspberrypi.org/forums/viewtopic.php?f=38=202382

  but there haven't been any responses to date.

Anyone here got any ideas?  For convenience, I'm working with the two adaptors 
plugged 
into my desktop PC (Dell Optiplex), but should be able to transfer the 
technique to the Pi 
once I've worked out the trick.  (BTW aplay -L gives a lot more info but I 
couldn't see 
anything in there to tie the hw: channel to the Adaptor's ID string.)

-- 



Terry Coles
-- 
Next meeting:  Bournemouth, Tuesday, 2018-01-09 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR