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
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.
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
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,
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
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
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
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
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
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
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
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
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:
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
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
15 matches
Mail list logo
