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
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
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
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
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
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
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
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
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
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
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
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?
>
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
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.
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');
>
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');
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
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
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
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*)’:
>
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
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
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
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
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
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
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
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
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
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/
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
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
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
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
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:
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:
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
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
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
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
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
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
56 matches
Mail list logo
