Pi sound
22 views
Skip to first unread message
Brian Jordan
Mar 8, 2021, 12:18:26 PM3/8/21
to
I have been offered a small USB speaker to try with my Pi and I note
there is an unused USB port on the computer. Question is whether
connecting the speaker to the Pi would let me play my long unheard
Maestro files? If this is a non-starter then nothing is lost, if making
it happen requires more software and hoop jumpimng I'd like to give it a
try. All thoughts appreciated.
B
--
_____________________________________________________________________
Brian Jordan
RISC OS 5.28 on Raspberry Pi
_____________________________________________________________________
there is an unused USB port on the computer. Question is whether
connecting the speaker to the Pi would let me play my long unheard
Maestro files? If this is a non-starter then nothing is lost, if making
it happen requires more software and hoop jumpimng I'd like to give it a
try. All thoughts appreciated.
B
--
_____________________________________________________________________
Brian Jordan
RISC OS 5.28 on Raspberry Pi
_____________________________________________________________________
Richard Ashbery
Mar 8, 2021, 2:54:07 PM3/8/21
to
In article <590a157d4eb...@btinternet.com>, Brian Jordan
corrected.
With my ARMX6 I can connect a digital to analogue converter from one
of the usb ports to an amplifier with some software from the audio
specialist, Jim Lesurf (http://www.audiomisc.co.uk/software) but even
this method may not work on the Raspberry Pi. Unfortunately DAC devices
can be expensive but the quality from devices like Behringer UCA202 is
excellent.
Richard
<brian....@btinternet.com> wrote:
> I have been offered a small USB speaker to try with my Pi and I
> note there is an unused USB port on the computer. Question is
> whether connecting the speaker to the Pi would let me play my long
> unheard Maestro files? If this is a non-starter then nothing is
> lost, if making it happen requires more software and hoop jumpimng
> I'd like to give it a try. All thoughts appreciated. B
I doubt this is possible under RISC OS on the R-Pi. I stand to be
> I have been offered a small USB speaker to try with my Pi and I
> note there is an unused USB port on the computer. Question is
> whether connecting the speaker to the Pi would let me play my long
> unheard Maestro files? If this is a non-starter then nothing is
> lost, if making it happen requires more software and hoop jumpimng
> I'd like to give it a try. All thoughts appreciated. B
corrected.
With my ARMX6 I can connect a digital to analogue converter from one
of the usb ports to an amplifier with some software from the audio
specialist, Jim Lesurf (http://www.audiomisc.co.uk/software) but even
this method may not work on the Raspberry Pi. Unfortunately DAC devices
can be expensive but the quality from devices like Behringer UCA202 is
excellent.
Richard
Tim Hill
Mar 8, 2021, 3:57:09 PM3/8/21
to
In article <590a2380...@invalid.addr.uk>, Richard Ashbery
As a USB-only speaker must contain a DAC of some sort, are !USBPlayer and
its companion apps on that page worth trying?
its companion apps on that page worth trying?
Jim Lesurf
Mar 9, 2021, 6:02:21 AM3/9/21
to
In article <590a28...@invalid.org.uk>, Tim Hill <t...@invalid.org.uk>
wrote:
> > With my ARMX6 I can connect a digital to analogue converter from one
> > of the usb ports to an amplifier with some software from the audio
> > specialist, Jim Lesurf (http://www.audiomisc.co.uk/software) but even
> > this method may not work on the Raspberry Pi. Unfortunately DAC
> > devices can be expensive but the quality from devices like Behringer
> > UCA202 is excellent.
> As a USB-only speaker must contain a DAC of some sort, are !USBPlayer
> and its companion apps on that page worth trying?
I'm afraid there is a stark 'binary divide' here between the 'haves' and
the 'have nots'!
In essence, if you are using the OS provided with machines like the ARMX6,
ArminiX, etc, they you can expect to be able to use USB Audio devices.
e.g. I'm currently using and developing !USBAudioScopePlus. This is already
*symultaneously* here playing out up to 192k/24 stereo *and* capturing up
to 192k/24 stereo via suitable USB Audio devices like the 3rd Gen Focusrite
2i2 / DACMagic Plus, etc. Running on my ARMX6. Uses a library kindly
created by Colin G. that makes writing programs that use USB Audio a
doddle. Must be, as even an idiot like me can do it!
The results aren't simply 'Hi Fi quality' they are good enough for lab
measurement purposes. The machine is clearly able to do this without any
difficulties. Simply playing or recording stereo audio using USB is a
doddle, and a number of programs to do it are available. The quality will
depend on your choice of USB device and the source of the audio info.
The OS will (thanks to Jason T.) gain 32 bit audio capability at some point
and then this can be integrated with the USB to open up audio with more
than 16 bits per sample, etc, for user software like DCD, etc. So all that
looks excellent - for the future.
All of which is excellent news. BUT...
Apologies for the following rant, but the following situation seems utterly
crazy to me! I've been banging my head up against this for years! :-/
However there are two big snags:
1) ROOL have never bothered to impliment the relevant support in their
versions of the OS. No real sign of interest in what has been offerred.
2) IIUC Some hardware *can't* support the required USB transfer modes. So
you'd need to choose your machine with care.
The first point continues to baffle me and others who have worked on this
because the reasons they gave in the past simply don't seem to stand up. So
I've concluded they either feel "Cannae Be Bothered, more interested in
other things", or "Not Invented Here" .
The second I can't comment on in detail wrt the 'Pi' family as I've not
used any of them. If someone told me which versions may provide the
required USB transfer modes it would be worth knowing, at least. And might
then be possible to kludge and add-on like the old moduled Dave and Colin
wrote and are available from my website. But I dunno as I don't have any
experience with the 'Pi's.
Macs/Doze/Linux have had USB Audio support for many years, and it is now
pretty much routine for users to choose USB devices for audio. The
Focusrite and DACMagic Plus are popular examples of the devices that have
been sold for this large market. But when it comes to RO we have two
classes of users at present. Crazy when even cheap 'Turntables', etc, tend
to have a USB port!
So at the moment if you want to join the 21st century for audio, you need
to choose your hardware and OS source with that in mind.
Jim
--
Please use the address on the audiomisc page if you wish to email me.
Electronics https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc http://www.audiomisc.co.uk/index.html
wrote:
> > With my ARMX6 I can connect a digital to analogue converter from one
> > of the usb ports to an amplifier with some software from the audio
> > specialist, Jim Lesurf (http://www.audiomisc.co.uk/software) but even
> > this method may not work on the Raspberry Pi. Unfortunately DAC
> > devices can be expensive but the quality from devices like Behringer
> > UCA202 is excellent.
> As a USB-only speaker must contain a DAC of some sort, are !USBPlayer
> and its companion apps on that page worth trying?
the 'have nots'!
In essence, if you are using the OS provided with machines like the ARMX6,
ArminiX, etc, they you can expect to be able to use USB Audio devices.
e.g. I'm currently using and developing !USBAudioScopePlus. This is already
*symultaneously* here playing out up to 192k/24 stereo *and* capturing up
to 192k/24 stereo via suitable USB Audio devices like the 3rd Gen Focusrite
2i2 / DACMagic Plus, etc. Running on my ARMX6. Uses a library kindly
created by Colin G. that makes writing programs that use USB Audio a
doddle. Must be, as even an idiot like me can do it!
The results aren't simply 'Hi Fi quality' they are good enough for lab
measurement purposes. The machine is clearly able to do this without any
difficulties. Simply playing or recording stereo audio using USB is a
doddle, and a number of programs to do it are available. The quality will
depend on your choice of USB device and the source of the audio info.
The OS will (thanks to Jason T.) gain 32 bit audio capability at some point
and then this can be integrated with the USB to open up audio with more
than 16 bits per sample, etc, for user software like DCD, etc. So all that
looks excellent - for the future.
All of which is excellent news. BUT...
Apologies for the following rant, but the following situation seems utterly
crazy to me! I've been banging my head up against this for years! :-/
However there are two big snags:
1) ROOL have never bothered to impliment the relevant support in their
versions of the OS. No real sign of interest in what has been offerred.
2) IIUC Some hardware *can't* support the required USB transfer modes. So
you'd need to choose your machine with care.
The first point continues to baffle me and others who have worked on this
because the reasons they gave in the past simply don't seem to stand up. So
I've concluded they either feel "Cannae Be Bothered, more interested in
other things", or "Not Invented Here" .
The second I can't comment on in detail wrt the 'Pi' family as I've not
used any of them. If someone told me which versions may provide the
required USB transfer modes it would be worth knowing, at least. And might
then be possible to kludge and add-on like the old moduled Dave and Colin
wrote and are available from my website. But I dunno as I don't have any
experience with the 'Pi's.
Macs/Doze/Linux have had USB Audio support for many years, and it is now
pretty much routine for users to choose USB devices for audio. The
Focusrite and DACMagic Plus are popular examples of the devices that have
been sold for this large market. But when it comes to RO we have two
classes of users at present. Crazy when even cheap 'Turntables', etc, tend
to have a USB port!
So at the moment if you want to join the 21st century for audio, you need
to choose your hardware and OS source with that in mind.
Jim
--
Please use the address on the audiomisc page if you wish to email me.
Electronics https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc http://www.audiomisc.co.uk/index.html
Brian Jordan
Mar 9, 2021, 6:22:57 AM3/9/21
to
> I have been offered a small USB speaker to try with my Pi and I note
> there is an unused USB port on the computer. Question is whether
> connecting the speaker to the Pi would let me play my long unheard
> Maestro files? If this is a non-starter then nothing is lost, if making
> it happen requires more software and hoop jumpimng I'd like to give it a
> try. All thoughts appreciated.
> B
Thanks for your replies, two (from Richard and Tim) offering a measure of
> there is an unused USB port on the computer. Question is whether
> connecting the speaker to the Pi would let me play my long unheard
> Maestro files? If this is a non-starter then nothing is lost, if making
> it happen requires more software and hoop jumpimng I'd like to give it a
> try. All thoughts appreciated.
> B
hope and then Jim's comprehensive explanation of why I should tell my son
to put the speaker back in his loft and not bother bring it around.
druck
Mar 9, 2021, 7:40:25 AM3/9/21
to
On 08/03/2021 17:18, Brian Jordan wrote:
> I have been offered a small USB speaker to try with my Pi and I note
> there is an unused USB port on the computer. Question is whether
> connecting the speaker to the Pi would let me play my long unheard
> Maestro files? If this is a non-starter then nothing is lost, if making
> it happen requires more software and hoop jumpimng I'd like to give it a
> try. All thoughts appreciated.
I assume the reason you haven't got audio on your Pi is that you are
> I have been offered a small USB speaker to try with my Pi and I note
> there is an unused USB port on the computer. Question is whether
> connecting the speaker to the Pi would let me play my long unheard
> Maestro files? If this is a non-starter then nothing is lost, if making
> it happen requires more software and hoop jumpimng I'd like to give it a
> try. All thoughts appreciated.
using an old VGA monitor with it? If so do your eyes and ears a favour
and get a HDMI one. Full HD monitors in any size are very cheap, make
sure you get one with either built in speakers and/or an audio output to
use with external speakers. If you've got a Pi 4, you can go 4K.
---druck
Jim Lesurf
Mar 9, 2021, 7:59:59 AM3/9/21
to
In article <590a78c747b...@btinternet.com>, Brian Jordan
up in the comment: "I keep telling people, there's no call for it!" :-/
TBH I regard the current situation as being in the area between
"rediculous", and "laughable" given the way USB Audio is now *THE* common
standard for Windows, Macs, and Linux. Even Pro studios tend to use it.
Certainly many musicians and small studios do, as do HiFi people.
And although Focurite refuse to support or help Linux, the Linux
'Musicians' have sorted out even their control interface of the Focusrite
devices that have many channels. (The 2i2 works with RO 'out of the box'.)
The only trailers here are RO! Frankly, ROOL in particular. As a result RO
will still look like a 'toy OS' to many people who take USB Audio for
granted. Bit like saying, "Sorry RO can't do HDMI, only analogue video"!
Yet it is quite capable of using USB Audio and at high quality levels.
<brian....@btinternet.com> wrote:
> In article <590a157d4eb...@btinternet.com>, Brian Jordan
> <brian....@btinternet.com> wrote:
> > I have been offered a small USB speaker to try with my Pi and I note
> > there is an unused USB port on the computer. Question is whether
> > connecting the speaker to the Pi would let me play my long unheard
> > Maestro files? If this is a non-starter then nothing is lost, if
> > making it happen requires more software and hoop jumpimng I'd like to
> > give it a try. All thoughts appreciated. B
> Thanks for your replies, two (from Richard and Tim) offering a measure
> of hope and then Jim's comprehensive explanation of why I should tell my
> son to put the speaker back in his loft and not bother bring it around. B
The problem with that is that it repeats us being in the situation summed
> In article <590a157d4eb...@btinternet.com>, Brian Jordan
> <brian....@btinternet.com> wrote:
> > I have been offered a small USB speaker to try with my Pi and I note
> > there is an unused USB port on the computer. Question is whether
> > connecting the speaker to the Pi would let me play my long unheard
> > Maestro files? If this is a non-starter then nothing is lost, if
> > making it happen requires more software and hoop jumpimng I'd like to
> > give it a try. All thoughts appreciated. B
> Thanks for your replies, two (from Richard and Tim) offering a measure
> of hope and then Jim's comprehensive explanation of why I should tell my
> son to put the speaker back in his loft and not bother bring it around. B
up in the comment: "I keep telling people, there's no call for it!" :-/
TBH I regard the current situation as being in the area between
"rediculous", and "laughable" given the way USB Audio is now *THE* common
standard for Windows, Macs, and Linux. Even Pro studios tend to use it.
Certainly many musicians and small studios do, as do HiFi people.
And although Focurite refuse to support or help Linux, the Linux
'Musicians' have sorted out even their control interface of the Focusrite
devices that have many channels. (The 2i2 works with RO 'out of the box'.)
The only trailers here are RO! Frankly, ROOL in particular. As a result RO
will still look like a 'toy OS' to many people who take USB Audio for
granted. Bit like saying, "Sorry RO can't do HDMI, only analogue video"!
Yet it is quite capable of using USB Audio and at high quality levels.
Jim Lesurf
Mar 9, 2021, 10:34:39 AM3/9/21
to
to send to a better DAC.[1] Won't help if you want to do recordings from a
mic or something like an ADC, though.
Jim
[1] Note, though, that many monitors limit what they send to an spdif or
optical output. Some are nailed to 48k rate, for example, so will mess up
even bog-standard CD material. (sigh) It's a bungle out there!...
Brian Jordan
Mar 9, 2021, 12:13:23 PM3/9/21
to
> On 08/03/2021 17:18, Brian Jordan wrote:
[Snip]
> >... All thoughts appreciated.
> I assume the reason you haven't got audio on your Pi is that you are
> using an old VGA monitor with it? If so do your eyes and ears a favour
> and get a HDMI one. Full HD monitors in any size are very cheap, make
> sure you get one with either built in speakers and/or an audio output
> to use with external speakers. If you've got a Pi 4, you can go 4K.
speakers. The PC (VGA output only) is connected to the VGA input and
plays sound through speakers connected directly to it. The RPi is
connected to the monitor HDMI socket. I am able to share the monitor via
onscreen menu selections and the wireless keyboard/mouse is shared using
a USB sharing switch. The best option seems to be that of getting a new
monitor with built in speakers.
[1] DEll S2340L 1920 x 1080 16 million colours.
druck
Mar 9, 2021, 3:44:01 PM3/9/21
to
On 09/03/2021 17:13, Brian Jordan wrote:
> In article <s27qbo$2nq$1...@dont-email.me>,
> druck <ne...@druck.org.uk> wrote:
>> I assume the reason you haven't got audio on your Pi is that you are
>> using an old VGA monitor with it? If so do your eyes and ears a favour
>> and get a HDMI one. Full HD monitors in any size are very cheap, make
>> sure you get one with either built in speakers and/or an audio output
>> to use with external speakers. If you've got a Pi 4, you can go 4K.
>
> Nearly! The monitor [1] has one VGA input and one HDMI input but no
> speakers. The PC (VGA output only) is connected to the VGA input and
> plays sound through speakers connected directly to it. The RPi is
> connected to the monitor HDMI socket. I am able to share the monitor via
> onscreen menu selections and the wireless keyboard/mouse is shared using
> a USB sharing switch. The best option seems to be that of getting a new
> monitor with built in speakers.
For HDMI monitors without speakers/audio out you can get a HDMI audio
> In article <s27qbo$2nq$1...@dont-email.me>,
> druck <ne...@druck.org.uk> wrote:
>> I assume the reason you haven't got audio on your Pi is that you are
>> using an old VGA monitor with it? If so do your eyes and ears a favour
>> and get a HDMI one. Full HD monitors in any size are very cheap, make
>> sure you get one with either built in speakers and/or an audio output
>> to use with external speakers. If you've got a Pi 4, you can go 4K.
>
> Nearly! The monitor [1] has one VGA input and one HDMI input but no
> speakers. The PC (VGA output only) is connected to the VGA input and
> plays sound through speakers connected directly to it. The RPi is
> connected to the monitor HDMI socket. I am able to share the monitor via
> onscreen menu selections and the wireless keyboard/mouse is shared using
> a USB sharing switch. The best option seems to be that of getting a new
> monitor with built in speakers.
extractor box. There are plenty on Amazon, you can take your pick of
3.5mm / phono / SPDIF output at various price points (which probably
have no relation to DAC quality).
---druck
charles
Mar 9, 2021, 4:26:39 PM3/9/21
to
In article <s28mmg$rn2$1...@dont-email.me>,
I have one of these which interrupts the HDMI signals so I can still feed
the monitor. The audio (via 3,5mm jack) goes into a cheap sound bar which
is so much better than the monitor's in-builtb speakers.
--
from KT24 in Surrey, England
"I'd rather die of exhaustion than die of boredom" Thomas Carlyle
the monitor. The audio (via 3,5mm jack) goes into a cheap sound bar which
is so much better than the monitor's in-builtb speakers.
--
from KT24 in Surrey, England
"I'd rather die of exhaustion than die of boredom" Thomas Carlyle
Chris Newman
Mar 9, 2021, 5:46:24 PM3/9/21
to
I bought a small power speaker on Amazon and stuck it in that. Works
quite well.
--
Chris Newman
Steve Fryatt
Mar 9, 2021, 6:35:04 PM3/9/21
to
On 9 Mar, Jim Lesurf wrote in message
<590a76d...@audiomisc.co.uk>:
> 1) ROOL have never bothered to impliment the relevant support in their
> versions of the OS. No real sign of interest in what has been offerred.
[snip]
> The first point continues to baffle me and others who have worked on this
> because the reasons they gave in the past simply don't seem to stand up.
> So I've concluded they either feel "Cannae Be Bothered, more interested in
> other things", or "Not Invented Here" .
I've just had a read of some of the relevant merge request comments, and am
going to suggest that you're maybe omitting a little bit of the story.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
<590a76d...@audiomisc.co.uk>:
> 1) ROOL have never bothered to impliment the relevant support in their
> versions of the OS. No real sign of interest in what has been offerred.
> The first point continues to baffle me and others who have worked on this
> because the reasons they gave in the past simply don't seem to stand up.
> So I've concluded they either feel "Cannae Be Bothered, more interested in
> other things", or "Not Invented Here" .
going to suggest that you're maybe omitting a little bit of the story.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Jim Lesurf
Mar 10, 2021, 6:22:43 AM3/10/21
to
In article <mpro.qpq6es00...@stevefryatt.org.uk>, Steve Fryatt
Yes. Accepted. However...
The problem is that it is now a looooooooooooooooong! story over *years*
whilst (ROOL) users sit and wait, and wait, and wait. And the 'reasons'
I've seen given by some in the past have been flatly contradicted by others
who have spoken to me. So perhaps you can excuse some frustration on my
part. Particularly when I've been writing software that *some* RO users can
use, but others will be excluded for reasons outwith my control!
The reality is that the non-ROOL OS has now had USB Audio for *years*
whilst ROOL have shown zero signs of any progress. Even when in the past I
offerred money and others offerred code, etc. So whatever reasons ROOL
think they have, I'd say they should reconsider and get something done. For
the sake of *users* - including those potential ones who look at RO from
outside, notice this, and it makes them think RO is a 'toy' OS. It is NOT
good for the future of the OS to let that go on happening. NOR for RO users
who may want good audio playout and/or capture, because of the dominance
USB Audio now has over hardware used by so many people who take audio
seriously.
With Jason working on a new, extended 32-bit Sound System this is, I
think, now more urgent that it was in the past. And the basis for USB
Audio is already available, and has been for some time. Add to that
the convenience and price of something like a Pi based setup for
playout or *recording* and it would be a package very attractive to
many people.
As I've said, this looks as ridiculous to 'outsiders' as if we'd stuck
with analog RGB monitors, and it can only do harm to promoting the OS.
I don't like saying any of the above because in all other ways I wish to
support ROOL and appreciate what they *do* do. So I wish them well, but
also wish they'd re-think this and then get their version of the OS up to
date. For *their* benefit as well as ours, and for the new users it will
help attract rather than deter.
The problem is that it is now a looooooooooooooooong! story over *years*
whilst (ROOL) users sit and wait, and wait, and wait. And the 'reasons'
I've seen given by some in the past have been flatly contradicted by others
who have spoken to me. So perhaps you can excuse some frustration on my
part. Particularly when I've been writing software that *some* RO users can
use, but others will be excluded for reasons outwith my control!
The reality is that the non-ROOL OS has now had USB Audio for *years*
whilst ROOL have shown zero signs of any progress. Even when in the past I
offerred money and others offerred code, etc. So whatever reasons ROOL
think they have, I'd say they should reconsider and get something done. For
the sake of *users* - including those potential ones who look at RO from
outside, notice this, and it makes them think RO is a 'toy' OS. It is NOT
good for the future of the OS to let that go on happening. NOR for RO users
who may want good audio playout and/or capture, because of the dominance
USB Audio now has over hardware used by so many people who take audio
seriously.
With Jason working on a new, extended 32-bit Sound System this is, I
think, now more urgent that it was in the past. And the basis for USB
Audio is already available, and has been for some time. Add to that
the convenience and price of something like a Pi based setup for
playout or *recording* and it would be a package very attractive to
many people.
As I've said, this looks as ridiculous to 'outsiders' as if we'd stuck
with analog RGB monitors, and it can only do harm to promoting the OS.
I don't like saying any of the above because in all other ways I wish to
support ROOL and appreciate what they *do* do. So I wish them well, but
also wish they'd re-think this and then get their version of the OS up to
date. For *their* benefit as well as ours, and for the new users it will
help attract rather than deter.
Jim Lesurf
Mar 10, 2021, 6:22:43 AM3/10/21
to
> For HDMI monitors without speakers/audio out you can get a HDMI audio
> extractor box. There are plenty on Amazon, you can take your pick of
> 3.5mm / phono / SPDIF output at various price points (which probably
> have no relation to DAC quality).
I'd add some comments to that.
> extractor box. There are plenty on Amazon, you can take your pick of
> 3.5mm / phono / SPDIF output at various price points (which probably
> have no relation to DAC quality).
As with monitors, the abilities of audio extractor boxes, etc, varies a
lot. Some do much the same as some monitors and turn everying (often
poorly) into 48k/20bit spdif. Others can export a much wider range and also
let you switch between HDMI inputs. But in many cases the bumf doesn't tell
you the full details.
DAC quality is a different issue. In many ways much easier to sort out
because the decent DACs will have clear specs, and are often measured for
HiFi Mags, etc, to check the reliability of maker's claims.
Theo
Mar 11, 2021, 5:12:21 AM3/11/21
to
Jim Lesurf <no...@audiomisc.co.uk> wrote:
> In article <mpro.qpq6es00...@stevefryatt.org.uk>, Steve Fryatt
> <ne...@stevefryatt.org.uk> wrote:
> > On 9 Mar, Jim Lesurf wrote in message <590a76d...@audiomisc.co.uk>:
>
> > > 1) ROOL have never bothered to impliment the relevant support in their
> > > versions of the OS. No real sign of interest in what has been offerred.
>
> > [snip]
>
> > > The first point continues to baffle me and others who have worked on
> > > this because the reasons they gave in the past simply don't seem to
> > > stand up. So I've concluded they either feel "Cannae Be Bothered, more
> > > interested in other things", or "Not Invented Here" .
>
> > I've just had a read of some of the relevant merge request comments, and
> > am going to suggest that you're maybe omitting a little bit of the story.
>
> Yes. Accepted. However...
I'm assuming the relevant merges are:
> In article <mpro.qpq6es00...@stevefryatt.org.uk>, Steve Fryatt
> <ne...@stevefryatt.org.uk> wrote:
> > On 9 Mar, Jim Lesurf wrote in message <590a76d...@audiomisc.co.uk>:
>
> > > 1) ROOL have never bothered to impliment the relevant support in their
> > > versions of the OS. No real sign of interest in what has been offerred.
>
> > [snip]
>
> > > The first point continues to baffle me and others who have worked on
> > > this because the reasons they gave in the past simply don't seem to
> > > stand up. So I've concluded they either feel "Cannae Be Bothered, more
> > > interested in other things", or "Not Invented Here" .
>
> > I've just had a read of some of the relevant merge request comments, and
> > am going to suggest that you're maybe omitting a little bit of the story.
>
> Yes. Accepted. However...
https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/USB/USBDriver/-/merge_requests/7
and (although this one isn't relevant to the Pi):
https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/USB/Controllers/EHCIDriver/-/merge_requests/3
On the first one ROOL are saying the code quality needs to be improved.
That's not an excuse or a delaying tactic, it's to make the code better
engineered and the history more intelligible to someone who later works on
it.
Tidying it up is relatively straightforward for the person who wrote the
code (since they know its environment and have means to test it), but
more difficult for someone else (especially for low level code like this
which isn't easy to write tests for and so specific hardware is needed).
> The problem is that it is now a looooooooooooooooong! story over *years*
> whilst (ROOL) users sit and wait, and wait, and wait. And the 'reasons'
> I've seen given by some in the past have been flatly contradicted by others
> who have spoken to me. So perhaps you can excuse some frustration on my
> part. Particularly when I've been writing software that *some* RO users can
> use, but others will be excluded for reasons outwith my control!
encourage the authors of that code to clean it up, or look for someone else
who could take on the effort to get this code over the line?
Theo
Jim Lesurf
Mar 12, 2021, 10:51:06 AM3/12/21
to
In article <kqb*aT...@news.chiark.greenend.org.uk>, Theo
reaction may be.
That said, two immediate points:
1) The URLs don't render here with NetSurf. Maybe because I have JS off
or need a new version. I'll try another browser later on.
2) Elsewhere in open source I've tended to see code accepted, and that
then spurs others to join in and improve it. They can't do that
for code they've not seen or been able to try out. As it is,
we've been waiting for Godot for quite some time... :-/
I can also say from experience that the code in the ARMX6 actually *works*
impressively well. I've been using it to symultaenously output and input
192k/24bit stereo streams and getting results of lab quality! As good as
specialist kit I know is used by pro engineers in the trade. And I'm
using some of the more popular high-performance 'domestic' USB items which
sell in large numbers to home users. So it does have the minor virtue of
working very well. It may be that the code 'offends the sensibilities' of
other programmers, or is difficult to maintain. But its absense may be having
a result of deterring an unknown number of potential users.
I'm not competent to comment on the quality of the code. Only on what it
can do in use. That test it passes nicely. As compared with... erm,
nothing at all from the ROOL OS as things stand.
So maybe sometimes the 'best' is the enemy of the 'good' so far as *users*
are concerned.
I appreciate that ROOL are busy and have many things to do.[1] However that
doesn't in my mind justify completely their apparently not doing *anything*
about this over a period of many years. My apologies if they have worked on
this but I've not seen any sign of it.
So perhaps you could also encourage ROOL to take this more seriously.
One factor I do NOT know is: What hardware (i.e. version of a Pi or
other board) includes the USB hardware that supports the required
transfer modes? And what doesn't?
I assume that ROOL must know this for the boards which their OS has
been generated for.
If nothing else, that info helps me when people keep asking me,
"will this run on my XYZ?" questions. If they have the 'wrong'
board I can say that's the problem. And if the reality is that
*none* of the boards outwith the ones that have USB Audio *now*
can provide the modes, then this becomes moot anyway.
I apologise in advance for any annoyance or offence my clearly ignorant
comments may cause. I don't intend that and wish to support and encourage
ROOL overall as they bigger work is welcome and essential. But please
forgive my frustration that this situation has endured for soooooo long!!
Jim
[1] You may recall that years ago I did raise paying to 'encourage'
ROOL in this area, but the reaction I got seemed unenthusiastic.
Left me feeling that even if happened for *a* generation of boards,
it might then lapse for later ones, for example.
<theom...@chiark.greenend.org.uk> wrote:
> Given that ROOL have plenty enough to worry about, perhaps you could
> encourage the authors of that code to clean it up, or look for someone
> else who could take on the effort to get this code over the line?
I'm happy to draw it to the attention of others and will see what their
> Given that ROOL have plenty enough to worry about, perhaps you could
> encourage the authors of that code to clean it up, or look for someone
> else who could take on the effort to get this code over the line?
reaction may be.
That said, two immediate points:
1) The URLs don't render here with NetSurf. Maybe because I have JS off
or need a new version. I'll try another browser later on.
2) Elsewhere in open source I've tended to see code accepted, and that
then spurs others to join in and improve it. They can't do that
for code they've not seen or been able to try out. As it is,
we've been waiting for Godot for quite some time... :-/
I can also say from experience that the code in the ARMX6 actually *works*
impressively well. I've been using it to symultaenously output and input
192k/24bit stereo streams and getting results of lab quality! As good as
specialist kit I know is used by pro engineers in the trade. And I'm
using some of the more popular high-performance 'domestic' USB items which
sell in large numbers to home users. So it does have the minor virtue of
working very well. It may be that the code 'offends the sensibilities' of
other programmers, or is difficult to maintain. But its absense may be having
a result of deterring an unknown number of potential users.
I'm not competent to comment on the quality of the code. Only on what it
can do in use. That test it passes nicely. As compared with... erm,
nothing at all from the ROOL OS as things stand.
So maybe sometimes the 'best' is the enemy of the 'good' so far as *users*
are concerned.
I appreciate that ROOL are busy and have many things to do.[1] However that
doesn't in my mind justify completely their apparently not doing *anything*
about this over a period of many years. My apologies if they have worked on
this but I've not seen any sign of it.
So perhaps you could also encourage ROOL to take this more seriously.
One factor I do NOT know is: What hardware (i.e. version of a Pi or
other board) includes the USB hardware that supports the required
transfer modes? And what doesn't?
I assume that ROOL must know this for the boards which their OS has
been generated for.
If nothing else, that info helps me when people keep asking me,
"will this run on my XYZ?" questions. If they have the 'wrong'
board I can say that's the problem. And if the reality is that
*none* of the boards outwith the ones that have USB Audio *now*
can provide the modes, then this becomes moot anyway.
I apologise in advance for any annoyance or offence my clearly ignorant
comments may cause. I don't intend that and wish to support and encourage
ROOL overall as they bigger work is welcome and essential. But please
forgive my frustration that this situation has endured for soooooo long!!
Jim
[1] You may recall that years ago I did raise paying to 'encourage'
ROOL in this area, but the reaction I got seemed unenthusiastic.
Left me feeling that even if happened for *a* generation of boards,
it might then lapse for later ones, for example.
Theo
Mar 12, 2021, 12:16:50 PM3/12/21
to
Jim Lesurf <no...@audiomisc.co.uk> wrote:
> In article <kqb*aT...@news.chiark.greenend.org.uk>, Theo
> <theom...@chiark.greenend.org.uk> wrote:
>
> > Given that ROOL have plenty enough to worry about, perhaps you could
> > encourage the authors of that code to clean it up, or look for someone
> > else who could take on the effort to get this code over the line?
>
> I'm happy to draw it to the attention of others and will see what their
> reaction may be.
>
> That said, two immediate points:
...
> In article <kqb*aT...@news.chiark.greenend.org.uk>, Theo
> <theom...@chiark.greenend.org.uk> wrote:
>
> > Given that ROOL have plenty enough to worry about, perhaps you could
> > encourage the authors of that code to clean it up, or look for someone
> > else who could take on the effort to get this code over the line?
>
> I'm happy to draw it to the attention of others and will see what their
> reaction may be.
>
> That said, two immediate points:
> 2) Elsewhere in open source I've tended to see code accepted, and that
> then spurs others to join in and improve it. They can't do that
> for code they've not seen or been able to try out. As it is,
> we've been waiting for Godot for quite some time... :-/
The common software development workflow today, as used by major projects
> then spurs others to join in and improve it. They can't do that
> for code they've not seen or been able to try out. As it is,
> we've been waiting for Godot for quite some time... :-/
like Linux, is that you develop and test your changes on a branch. When
they're ready you make a merge/pull requests against the main repository.
In the code review process there's a bit of back-and-forth asking you to
adjust the way you've done things, tidy up loose ends, etc. Once amended
satisfactorily, a suitable number of people approve the request and it
passes tests then it gets merged into the master branch. Since others tend
to consume the master branch (in the case of ROOL, this produces the daily
builds) it means the code in master is robust and has fewer 'ooops I broke
something, sorreeee' commits than there would be if changes got initially
committed.
Given this change is happening in the USB stack it's very important not to
break it, otherwise keyboards, mice and storage may not work any more. That
would be an awkward situation to get out of.
In this specific case the changes are against a 2-3 year old version of
sources than is current, so may not even cleanly apply.
> I appreciate that ROOL are busy and have many things to do.[1] However that
> doesn't in my mind justify completely their apparently not doing *anything*
> about this over a period of many years. My apologies if they have worked on
> this but I've not seen any sign of it.
>
> So perhaps you could also encourage ROOL to take this more seriously.
pushing a button. If the quality isn't up to scratch it's for the commiter
to improve it, it's not something ROOL can magically do without time, skills
and experience in this area.
The merge request mentions John Ballance and Colin Granville, so perhaps get
in touch with them and enquire how things are going, find out if there's any
problems?
> One factor I do NOT know is: What hardware (i.e. version of a Pi or
> other board) includes the USB hardware that supports the required
> transfer modes? And what doesn't?
although that's the USB pins on the charging port which are awkward to
access). The USB 3 port on the Pi 4 is a PCIe chip which is completely
different and similar to ports on PCs (and many other ARM boards at least at
USB 2 speeds).
All USB hardware should support isochronous mode that's used for sound,
although not every controller has RISC OS drivers for it. It looks like
John has been developing this code on the iMX6.
> I assume that ROOL must know this for the boards which their OS has
> been generated for.
>
> If nothing else, that info helps me when people keep asking me,
> "will this run on my XYZ?" questions. If they have the 'wrong'
> board I can say that's the problem. And if the reality is that
> *none* of the boards outwith the ones that have USB Audio *now*
> can provide the modes, then this becomes moot anyway.
on ROOL hardware, it's the absence of drivers that's the issue.
(I also don't know if RComp or others have their own USB code that hasn't
been contributed to the ROOL tree. In that case an existence proof may not
help).
> I apologise in advance for any annoyance or offence my clearly ignorant
> comments may cause. I don't intend that and wish to support and encourage
> ROOL overall as they bigger work is welcome and essential. But please
> forgive my frustration that this situation has endured for soooooo long!!
targets...
Theo
Steve Fryatt
Mar 12, 2021, 3:35:04 PM3/12/21
to
On 12 Mar, Jim Lesurf wrote in message
<590c09a...@audiomisc.co.uk>:
> I'm not competent to comment on the quality of the code. Only on what it
> can do in use. That test it passes nicely. As compared with... erm,
> nothing at all from the ROOL OS as things stand.
>
> So maybe sometimes the 'best' is the enemy of the 'good' so far as *users*
> are concerned.
When working on a collaborative project (like the OS, or NetSurf, or many
other things away from RISC OS), the process is generally that new code is
developed in a branch. Once ready to make available for wider testing, that
branch is brought up to date with the current code in the main/master/trunk
branch and then, once shown to build OK, is merged in so that it appears in
the test builds.
The key point here is the "brought up to date" bit. That is, the current
main/master/trunk code will be merged back into the branch until there are
no changes and everyone can be happy that merging the branch into the "live"
code will do *nothing* but add in the new feature. The problem is that the
longer the branch is separate, the further the "live" code can diverge, and
the harder it can be to resolve. It has to be resolved, however, because
otherwise you'll lose months or years of other unrelated developments as a
result.
The only people who can fix this are the branch developers. They're the ones
with the knowledge of their new code, and how any conflicting changes will
affect it. They might need to talk to those who have made those conflicting
changes, but in the end there's only really one group of people who can fix
them.
So the question isn't "best or good", it's "can this even be merged at all".
> I appreciate that ROOL are busy and have many things to do.[1] However
> that doesn't in my mind justify completely their apparently not doing
> *anything* about this over a period of many years. My apologies if they
> have worked on this but I've not seen any sign of it.
Perhaps you should actually go and *read* the comments in the merge requests
that Theo highlighted (other browsers than NetSurf are available)? It's
pretty clear that:
1. The original changes were not up to standard for merging into the nightly
builds (for the reasons above, and not for stylistic reasons), and so
2. ROOL did a lot of work to help get them up to standard, but
3. It takes two to tango, and the process seemed to stall, before
4. Subsequent merge requests appeared which undid all of the work that had
been done by ROOL, and were against a unclear version of the OS which
appears to be from a couple of years ago and so can't be merged into the
main source as it stands today.
> So perhaps you could also encourage ROOL to take this more seriously.
Perhaps /you/ could encourage the USB developers to take this more
seriously? It looks from the comments as if, were ROOL presented with a
merge request which could be merged, they would merge it. Or, if they were
presented with a merge request which looked as if it could be worked into a
state that could be merged, then they would help to get it over the line.
As it is, ROOL seem to think that they haven't got either of the above, so
all they can do is ask for the submitters to try again. It isn't as though
they haven't outlined what needs fixing: that's written in the comments.
This isn't just a ROOL rule, by the way; it's how most collaborative
projects (both Open Source and otherwise) work. In fact, it's pretty much
the *only* way that they can work, for very practical reasons.
<590c09a...@audiomisc.co.uk>:
> I'm not competent to comment on the quality of the code. Only on what it
> can do in use. That test it passes nicely. As compared with... erm,
> nothing at all from the ROOL OS as things stand.
>
> So maybe sometimes the 'best' is the enemy of the 'good' so far as *users*
> are concerned.
other things away from RISC OS), the process is generally that new code is
developed in a branch. Once ready to make available for wider testing, that
branch is brought up to date with the current code in the main/master/trunk
branch and then, once shown to build OK, is merged in so that it appears in
the test builds.
The key point here is the "brought up to date" bit. That is, the current
main/master/trunk code will be merged back into the branch until there are
no changes and everyone can be happy that merging the branch into the "live"
code will do *nothing* but add in the new feature. The problem is that the
longer the branch is separate, the further the "live" code can diverge, and
the harder it can be to resolve. It has to be resolved, however, because
otherwise you'll lose months or years of other unrelated developments as a
result.
The only people who can fix this are the branch developers. They're the ones
with the knowledge of their new code, and how any conflicting changes will
affect it. They might need to talk to those who have made those conflicting
changes, but in the end there's only really one group of people who can fix
them.
So the question isn't "best or good", it's "can this even be merged at all".
> I appreciate that ROOL are busy and have many things to do.[1] However
> that doesn't in my mind justify completely their apparently not doing
> *anything* about this over a period of many years. My apologies if they
> have worked on this but I've not seen any sign of it.
that Theo highlighted (other browsers than NetSurf are available)? It's
pretty clear that:
1. The original changes were not up to standard for merging into the nightly
builds (for the reasons above, and not for stylistic reasons), and so
2. ROOL did a lot of work to help get them up to standard, but
3. It takes two to tango, and the process seemed to stall, before
4. Subsequent merge requests appeared which undid all of the work that had
been done by ROOL, and were against a unclear version of the OS which
appears to be from a couple of years ago and so can't be merged into the
main source as it stands today.
> So perhaps you could also encourage ROOL to take this more seriously.
seriously? It looks from the comments as if, were ROOL presented with a
merge request which could be merged, they would merge it. Or, if they were
presented with a merge request which looked as if it could be worked into a
state that could be merged, then they would help to get it over the line.
As it is, ROOL seem to think that they haven't got either of the above, so
all they can do is ask for the submitters to try again. It isn't as though
they haven't outlined what needs fixing: that's written in the comments.
This isn't just a ROOL rule, by the way; it's how most collaborative
projects (both Open Source and otherwise) work. In fact, it's pretty much
the *only* way that they can work, for very practical reasons.
Jim Lesurf
Mar 13, 2021, 5:37:15 AM3/13/21
to
In article <mpro.qpvhts02...@stevefryatt.org.uk>, Steve Fryatt
that it *would* be what you call a 'branch' that initially would make
things easier to develop for some platforms, and eventually be improved
and end up merging and being more widely used.
The advantages being that more people could see and improve it,
co-operating more easily, etc, and that fairly quickly it could then be
adopted and tried out on specific hardware like the imx6.
That said, I've still not had a chance to read the pages referenced
earlier. Sorry about that, been distracted.
As both and engineer and experimental physicist I can well understand the
wish that things we build should be well made and as robust and 'elegant'
as possible.
TBH When developing measurement systems and techniques I used to enjoy
saying that my old research group tended to focus on requirements where we
could get results at least 3 orders of mag better than anyone else. :-) So
I can understand the wish for excellent engineering.
But the reality here is that USB Audio has made *NO* progress at all for
years on the ROOL OS front. Whereas it is working very well indeed
elsewhere. The whole point of open code seems to me to be to support people
being able to pool their contributions. Rejecting what was offerred
prevents that from starting. Indeed, it seems to me to have *discouraged*
some from helping.
There comes a time when - as an engineer paid to get a task done - I've had
to accept that a *working* system that does what people require may be more
important that a 'perfect' system we can't make as things stand when people
need it.
So I really think it is long past time for ROOL to change its stance on
this issue. As it is, they are WAY behind other OSs in an area many users
regard as a given.
Jim
<ne...@stevefryatt.org.uk> wrote:
> When working on a collaborative project (like the OS, or NetSurf, or
> many other things away from RISC OS), the process is generally that new
> code is developed in a branch. Once ready to make available for wider
> testing, that branch is brought up to date with the current code in the
> main/master/trunk branch and then, once shown to build OK, is merged in
> so that it appears in the test builds.
From what I have been told and IIUC: The intent when this was submitted was
> When working on a collaborative project (like the OS, or NetSurf, or
> many other things away from RISC OS), the process is generally that new
> code is developed in a branch. Once ready to make available for wider
> testing, that branch is brought up to date with the current code in the
> main/master/trunk branch and then, once shown to build OK, is merged in
> so that it appears in the test builds.
that it *would* be what you call a 'branch' that initially would make
things easier to develop for some platforms, and eventually be improved
and end up merging and being more widely used.
The advantages being that more people could see and improve it,
co-operating more easily, etc, and that fairly quickly it could then be
adopted and tried out on specific hardware like the imx6.
That said, I've still not had a chance to read the pages referenced
earlier. Sorry about that, been distracted.
As both and engineer and experimental physicist I can well understand the
wish that things we build should be well made and as robust and 'elegant'
as possible.
TBH When developing measurement systems and techniques I used to enjoy
saying that my old research group tended to focus on requirements where we
could get results at least 3 orders of mag better than anyone else. :-) So
I can understand the wish for excellent engineering.
But the reality here is that USB Audio has made *NO* progress at all for
years on the ROOL OS front. Whereas it is working very well indeed
elsewhere. The whole point of open code seems to me to be to support people
being able to pool their contributions. Rejecting what was offerred
prevents that from starting. Indeed, it seems to me to have *discouraged*
some from helping.
There comes a time when - as an engineer paid to get a task done - I've had
to accept that a *working* system that does what people require may be more
important that a 'perfect' system we can't make as things stand when people
need it.
So I really think it is long past time for ROOL to change its stance on
this issue. As it is, they are WAY behind other OSs in an area many users
regard as a given.
Jim
Jim Lesurf
Mar 13, 2021, 5:37:16 AM3/13/21
to
In article <lqb*-HU...@news.chiark.greenend.org.uk>, Theo
experimental or main version. Not for doing nothing.
And for years now I've not had any of the above problems. Yet this
apparently seems to have passed by ROOL.
> >
> > So perhaps you could also encourage ROOL to take this more seriously.
> I'm sure ROOL would be happy to accept patches that are suitable - it's
> just pushing a button. If the quality isn't up to scratch it's for the
> commiter to improve it, it's not something ROOL can magically do without
> time, skills and experience in this area.
But you *can* allow those who *do* have the experience to add 'branch'
code, etc. Thereby enabling more people to see, and test/improve. Not
simply reject it, blocking such sources of progress.
> The merge request mentions John Ballance and Colin Granville, so perhaps
> get in touch with them and enquire how things are going, find out if
> there's any problems?
Let me just say I am using a library Colin has developed to make use of the
USB Audio easier for more dimwitted programmers like myself. And one reason
I've been developing !USBScopeProbe is to test the limits of the audio and
its impact on the rest of the machine.
No problems evident. Indeed, works so well it has been quite impressive.
Currently 192k/24 bit in and out symultaneously without seeming to affect
anything else adversely. Textbook results.
I know that the code isn't perfect and has some quite specific limitations.
(True, of course, for all code in the real world.) But it is MUCH better
than not having any USB Audio capabilty, and would be fine for the vast
majority of users who want good stereo audio capability. And ultimately a
basis for extended provision if people then wanted it.
> All USB hardware should support isochronous mode that's used for sound,
> although not every controller has RISC OS drivers for it. It looks like
> John has been developing this code on the iMX6.
The ArminiX also had the USB Audio. But I have no idea if it could work at
as high a level of transfer demand as the ArmX6.
So the question for the Pi's becomes "Which ones have a USB controller with
a RO driver that would allow this to work?"
> > I apologise in advance for any annoyance or offence my clearly
> > ignorant comments may cause. I don't intend that and wish to support
> > and encourage ROOL overall as they bigger work is welcome and
> > essential. But please forgive my frustration that this situation has
> > endured for soooooo long!!
> Understood. I'm just trying to channel your enthusiasm towards the
> right targets...
Well, a LOT of progress has been made... the problem is that it all remains
outwith the ROOL area. And without my making a fuss, no sign has emerged of
any interest from them. So for me, ROOL, *are* a 'target* in terms of
having them re-think their attitude to this topic.
TBH I've seen what seems like evidence to me that John and Colin have
wanted to work with ROOL. But I've not seen any the other way about on this
issue. Maybe that is unfair, but I'm having to judge on what I can see:
Non-ROOL OS now can deliver excellent USB Audio.
ROOL OS - nada.
And this has been so for years, now. So perhaps it should now change?
Jim
<theom...@chiark.greenend.org.uk> wrote:
> Jim Lesurf <no...@audiomisc.co.uk> wrote:
> > In article <kqb*aT...@news.chiark.greenend.org.uk>, Theo
> > <theom...@chiark.greenend.org.uk> wrote:
> Given this change is happening in the USB stack it's very important not
> to break it, otherwise keyboards, mice and storage may not work any
> more. That would be an awkward situation to get out of.
That is the argument for test and develop before offerring it as either an
> Jim Lesurf <no...@audiomisc.co.uk> wrote:
> > In article <kqb*aT...@news.chiark.greenend.org.uk>, Theo
> > <theom...@chiark.greenend.org.uk> wrote:
> Given this change is happening in the USB stack it's very important not
> to break it, otherwise keyboards, mice and storage may not work any
> more. That would be an awkward situation to get out of.
experimental or main version. Not for doing nothing.
And for years now I've not had any of the above problems. Yet this
apparently seems to have passed by ROOL.
> >
> > So perhaps you could also encourage ROOL to take this more seriously.
> I'm sure ROOL would be happy to accept patches that are suitable - it's
> just pushing a button. If the quality isn't up to scratch it's for the
> commiter to improve it, it's not something ROOL can magically do without
> time, skills and experience in this area.
code, etc. Thereby enabling more people to see, and test/improve. Not
simply reject it, blocking such sources of progress.
> The merge request mentions John Ballance and Colin Granville, so perhaps
> get in touch with them and enquire how things are going, find out if
> there's any problems?
USB Audio easier for more dimwitted programmers like myself. And one reason
I've been developing !USBScopeProbe is to test the limits of the audio and
its impact on the rest of the machine.
No problems evident. Indeed, works so well it has been quite impressive.
Currently 192k/24 bit in and out symultaneously without seeming to affect
anything else adversely. Textbook results.
I know that the code isn't perfect and has some quite specific limitations.
(True, of course, for all code in the real world.) But it is MUCH better
than not having any USB Audio capabilty, and would be fine for the vast
majority of users who want good stereo audio capability. And ultimately a
basis for extended provision if people then wanted it.
> All USB hardware should support isochronous mode that's used for sound,
> although not every controller has RISC OS drivers for it. It looks like
> John has been developing this code on the iMX6.
as high a level of transfer demand as the ArmX6.
So the question for the Pi's becomes "Which ones have a USB controller with
a RO driver that would allow this to work?"
> > I apologise in advance for any annoyance or offence my clearly
> > ignorant comments may cause. I don't intend that and wish to support
> > and encourage ROOL overall as they bigger work is welcome and
> > essential. But please forgive my frustration that this situation has
> > endured for soooooo long!!
> Understood. I'm just trying to channel your enthusiasm towards the
> right targets...
outwith the ROOL area. And without my making a fuss, no sign has emerged of
any interest from them. So for me, ROOL, *are* a 'target* in terms of
having them re-think their attitude to this topic.
TBH I've seen what seems like evidence to me that John and Colin have
wanted to work with ROOL. But I've not seen any the other way about on this
issue. Maybe that is unfair, but I'm having to judge on what I can see:
Non-ROOL OS now can deliver excellent USB Audio.
ROOL OS - nada.
And this has been so for years, now. So perhaps it should now change?
Jim
Steve Fryatt
Mar 13, 2021, 6:35:04 AM3/13/21
to
On 13 Mar, Jim Lesurf wrote in message
<590c831...@audiomisc.co.uk>:
> In article <lqb*-HU...@news.chiark.greenend.org.uk>, Theo
> <theom...@chiark.greenend.org.uk> wrote:
>
> > I'm sure ROOL would be happy to accept patches that are suitable - it's
> > just pushing a button. If the quality isn't up to scratch it's for the
> > commiter to improve it, it's not something ROOL can magically do without
> > time, skills and experience in this area.
>
> But you *can* allow those who *do* have the experience to add 'branch'
> code, etc. Thereby enabling more people to see, and test/improve. Not
> simply reject it, blocking such sources of progress.
The code is already there, in (several?) branches on the ROOL site. It's
visible to users. You could even download it yourself, build it and try it
out; perhaps even fix up some of the problems that stop it being merged.
So what you are requesting here is already done, and has been for some time.
What hasn't happened here is for the code to get into the nightly builds,
for reasons that have now been explained to you in great detail.
> Well, a LOT of progress has been made... the problem is that it all
> remains outwith the ROOL area. And without my making a fuss, no sign has
> emerged of any interest from them. So for me, ROOL, *are* a 'target* in
> terms of having them re-think their attitude to this topic.
On the contrary, ROOL seem to have made a fair bit of effort to get the
branches mergable with the main sources, without success. Have a read of
those comments on GitLab which Theo pointed you towards.
It's unclear to me what more you expect ROOL to do. They do not have the
resources to fix up all of the changes that they're asked to merge; no
project like this does. They have to rely on the project developers to get
their merge requests into a form where the merge is an automated process.
They have always been very clear about this, and about what contributors
will need to do in order to get code into the OS.
It's also clear that ROOL do not go through the detail of what the code does
before merging it. Many things are merged, found to be undesirable for
whatever reason, and then undone.
All of the evidence available suggests that what is going on here is purely
practical: the code as supplied will not merge and needs to be fixed so that
it does. When it does, it will very likely be merged. If I'm correct, then
the people who can solve this are Colin and John, not ROOL.
<590c831...@audiomisc.co.uk>:
> In article <lqb*-HU...@news.chiark.greenend.org.uk>, Theo
> <theom...@chiark.greenend.org.uk> wrote:
>
> > I'm sure ROOL would be happy to accept patches that are suitable - it's
> > just pushing a button. If the quality isn't up to scratch it's for the
> > commiter to improve it, it's not something ROOL can magically do without
> > time, skills and experience in this area.
>
> But you *can* allow those who *do* have the experience to add 'branch'
> code, etc. Thereby enabling more people to see, and test/improve. Not
> simply reject it, blocking such sources of progress.
visible to users. You could even download it yourself, build it and try it
out; perhaps even fix up some of the problems that stop it being merged.
So what you are requesting here is already done, and has been for some time.
What hasn't happened here is for the code to get into the nightly builds,
for reasons that have now been explained to you in great detail.
> Well, a LOT of progress has been made... the problem is that it all
> remains outwith the ROOL area. And without my making a fuss, no sign has
> emerged of any interest from them. So for me, ROOL, *are* a 'target* in
> terms of having them re-think their attitude to this topic.
branches mergable with the main sources, without success. Have a read of
those comments on GitLab which Theo pointed you towards.
It's unclear to me what more you expect ROOL to do. They do not have the
resources to fix up all of the changes that they're asked to merge; no
project like this does. They have to rely on the project developers to get
their merge requests into a form where the merge is an automated process.
They have always been very clear about this, and about what contributors
will need to do in order to get code into the OS.
It's also clear that ROOL do not go through the detail of what the code does
before merging it. Many things are merged, found to be undesirable for
whatever reason, and then undone.
All of the evidence available suggests that what is going on here is purely
practical: the code as supplied will not merge and needs to be fixed so that
it does. When it does, it will very likely be merged. If I'm correct, then
the people who can solve this are Colin and John, not ROOL.
Steve Fryatt
Mar 13, 2021, 6:55:03 AM3/13/21
to
On 13 Mar, Jim Lesurf wrote in message
<590c80f...@audiomisc.co.uk>:
> From what I have been told and IIUC: The intent when this was submitted
> was that it *would* be what you call a 'branch' that initially would make
> things easier to develop for some platforms, and eventually be improved
> and end up merging and being more widely used.
>
> The advantages being that more people could see and improve it,
> co-operating more easily, etc, and that fairly quickly it could then be
> adopted and tried out on specific hardware like the imx6.
The branch is there; I've just looked at it.
> That said, I've still not had a chance to read the pages referenced
> earlier. Sorry about that, been distracted.
>
> As both and engineer and experimental physicist I can well understand the
> wish that things we build should be well made and as robust and 'elegant'
> as possible.
That's also a straw man. The comments suggest that the problem isn't the
elegance of the code, but the fact that as presented, it isn't mergable.
Amongst the comments is the following, which seems very relevant:
"The code appears to have branched from somewhere earlier in time than the
head (example: the DEVICEFSISBROKEN switch was removed in January 2018)
and so is already out of sync & needs to be rebased even ignoring the
above notes."
So, merging this in will undo other work done to the OS in recent months. As
I noted, the developers need to spend some time merging the recent OS
changes back into their branch, so that the only things that it will alter
in the main OS are the things that they have worked on.
It must *NOT* undo other people's unrelated work. That's how old bugs return
to the OS after being fixed.
There's also this, which has a bearing on my "two to tango" comment:
"Sadly, these changes appear to have lost all of the hard work that we did
with Colin in 2018 to improve them. Colin should have the latest set of
changes from 29-Jul-2018, along with details of what additional
improvements were needed (email chasers sent in August & September 2018)
at the time of review."
Did Colin ever respond to those emails? If not, that's probably why things
stalled when they did. And if he did, maybe ROOL didn't receive his replies
-- did he follow them up?
And why on earth has code been resubmitted this time around with all of the
previous work to prepare for inclusion stripped out again?
> There comes a time when - as an engineer paid to get a task done - I've
> had to accept that a *working* system that does what people require may be
> more important that a 'perfect' system we can't make as things stand when
> people need it.
The problem as stated by ROOL in their most recent comments is that the code
hasn't been prepared in a way that can be merged into the main code.
Not that it's "not perfect". Rather the simple fact that merging it in will
completely break the main OS code because it can't be merged cleanly. It's a
workflow problem, not a code quality problem.
> So I really think it is long past time for ROOL to change its stance on
> this issue.
What do you propose that they do, given that they don't think that the code
as supplied can be merged?
ROOL do not have the time or resource to fix people's code for them. It's
clear from the above that they have spent time trying to help, but that for
whatever reason this didn't get the problems resolved.
<590c80f...@audiomisc.co.uk>:
> From what I have been told and IIUC: The intent when this was submitted
> was that it *would* be what you call a 'branch' that initially would make
> things easier to develop for some platforms, and eventually be improved
> and end up merging and being more widely used.
>
> The advantages being that more people could see and improve it,
> co-operating more easily, etc, and that fairly quickly it could then be
> adopted and tried out on specific hardware like the imx6.
> That said, I've still not had a chance to read the pages referenced
> earlier. Sorry about that, been distracted.
>
> As both and engineer and experimental physicist I can well understand the
> wish that things we build should be well made and as robust and 'elegant'
> as possible.
elegance of the code, but the fact that as presented, it isn't mergable.
Amongst the comments is the following, which seems very relevant:
"The code appears to have branched from somewhere earlier in time than the
head (example: the DEVICEFSISBROKEN switch was removed in January 2018)
and so is already out of sync & needs to be rebased even ignoring the
above notes."
So, merging this in will undo other work done to the OS in recent months. As
I noted, the developers need to spend some time merging the recent OS
changes back into their branch, so that the only things that it will alter
in the main OS are the things that they have worked on.
It must *NOT* undo other people's unrelated work. That's how old bugs return
to the OS after being fixed.
There's also this, which has a bearing on my "two to tango" comment:
"Sadly, these changes appear to have lost all of the hard work that we did
with Colin in 2018 to improve them. Colin should have the latest set of
changes from 29-Jul-2018, along with details of what additional
improvements were needed (email chasers sent in August & September 2018)
at the time of review."
Did Colin ever respond to those emails? If not, that's probably why things
stalled when they did. And if he did, maybe ROOL didn't receive his replies
-- did he follow them up?
And why on earth has code been resubmitted this time around with all of the
previous work to prepare for inclusion stripped out again?
> There comes a time when - as an engineer paid to get a task done - I've
> had to accept that a *working* system that does what people require may be
> more important that a 'perfect' system we can't make as things stand when
> people need it.
hasn't been prepared in a way that can be merged into the main code.
Not that it's "not perfect". Rather the simple fact that merging it in will
completely break the main OS code because it can't be merged cleanly. It's a
workflow problem, not a code quality problem.
> So I really think it is long past time for ROOL to change its stance on
> this issue.
as supplied can be merged?
ROOL do not have the time or resource to fix people's code for them. It's
clear from the above that they have spent time trying to help, but that for
whatever reason this didn't get the problems resolved.
Jim Lesurf
Mar 13, 2021, 10:48:40 AM3/13/21
to
On 13 Mar, no...@audiomisc.co.uk wrote:
> I've been developing !USBScopeProbe is to test the limits of the audio
> and its impact on the rest of the machine.
If anyone is interested I've put the current version of this here
> I've been developing !USBScopeProbe is to test the limits of the audio
> and its impact on the rest of the machine.
http://www.audiomisc.co.uk/software/USBScopePlus0p75.zip
as the version number indicates it isn't finished as yet. The main 'to do'
omissions are that the current version requires a Class 2 ( 4 bytes per
value) transfer for the DAC and doesn't work with Class 1 (2 bytes per value)
USB DACs. And I want to add in 'user defined' waveforms to allow people to
add their own.
A copy of my USBAudioProbe program is here
http://www.audiomisc.co.uk/software/USBAudioProbe2.zip
This will list any USB Audio devices it finds. That lets you check that you
do have suitable devices and the machine can access them. If you get no
list then either none are connected and/or your setup doesn't support USB
Audio.
Source code is provided. Mine is rubbish, but can still give good results
with an appropriate setup. The programs also example how to use Colin's
library.
Jim Lesurf
Mar 13, 2021, 1:36:23 PM3/13/21
to
In article <mpro.qpwnlb02...@stevefryatt.org.uk>, Steve Fryatt
understand that isn't a limit that applies to (many) others! :-)
I do note the other points you made in this posting and the following one.
I'll see if I can find out more, elsewhere.
The question in my mind is: given what you have said, which RPis, etc, have
this if the above was done? All? i.e. none have hardware that can't cope?
Given also that Colin and John have been mentioned more than once, a more
open question for people: Are there any other people who might be up for
this sort of thing, and capable? Note that Jason T. is 32-bitting the ROSS
and adding more capture/playout ability. Given that, the absence of
USB Audio will seem even odder to people. Whereas up to now the 16bit
limit of the ROSS has made good use of USB Audio problematic, as has the
tendency to lack any reasonably audio capture as standard.
[big snip]
Thanks,
<ne...@stevefryatt.org.uk> wrote:
> On 13 Mar, Jim Lesurf wrote in message <590c831...@audiomisc.co.uk>:
> > In article <lqb*-HU...@news.chiark.greenend.org.uk>, Theo
> > <theom...@chiark.greenend.org.uk> wrote:
> >
> > > I'm sure ROOL would be happy to accept patches that are suitable -
> > > it's just pushing a button. If the quality isn't up to scratch it's
> > > for the commiter to improve it, it's not something ROOL can
> > > magically do without time, skills and experience in this area.
> >
> > But you *can* allow those who *do* have the experience to add 'branch'
> > code, etc. Thereby enabling more people to see, and test/improve. Not
> > simply reject it, blocking such sources of progress.
> The code is already there, in (several?) branches on the ROOL site. It's
> visible to users. You could even download it yourself, build it and try
> it out; perhaps even fix up some of the problems that stop it being
> merged.
Actually, I think it is *way* beyond my skillset to do so. But I
> On 13 Mar, Jim Lesurf wrote in message <590c831...@audiomisc.co.uk>:
> > In article <lqb*-HU...@news.chiark.greenend.org.uk>, Theo
> > <theom...@chiark.greenend.org.uk> wrote:
> >
> > > I'm sure ROOL would be happy to accept patches that are suitable -
> > > it's just pushing a button. If the quality isn't up to scratch it's
> > > for the commiter to improve it, it's not something ROOL can
> > > magically do without time, skills and experience in this area.
> >
> > But you *can* allow those who *do* have the experience to add 'branch'
> > code, etc. Thereby enabling more people to see, and test/improve. Not
> > simply reject it, blocking such sources of progress.
> The code is already there, in (several?) branches on the ROOL site. It's
> visible to users. You could even download it yourself, build it and try
> it out; perhaps even fix up some of the problems that stop it being
> merged.
understand that isn't a limit that applies to (many) others! :-)
I do note the other points you made in this posting and the following one.
I'll see if I can find out more, elsewhere.
The question in my mind is: given what you have said, which RPis, etc, have
this if the above was done? All? i.e. none have hardware that can't cope?
Given also that Colin and John have been mentioned more than once, a more
open question for people: Are there any other people who might be up for
this sort of thing, and capable? Note that Jason T. is 32-bitting the ROSS
and adding more capture/playout ability. Given that, the absence of
USB Audio will seem even odder to people. Whereas up to now the 16bit
limit of the ROSS has made good use of USB Audio problematic, as has the
tendency to lack any reasonably audio capture as standard.
[big snip]
Thanks,
Jim Lesurf
Mar 14, 2021, 6:03:48 AM3/14/21
to
> I'm assuming the relevant merges are:
> https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/USB/USBDriver/-/merge_requests/7
> and (although this one isn't relevant to the Pi):
> https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/USB/Controllers/EHCIDriver/-/merge_requests/3
Sorry, but I'm having some trouble with following up this and some later
> https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/USB/USBDriver/-/merge_requests/7
> and (although this one isn't relevant to the Pi):
> https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/USB/Controllers/EHCIDriver/-/merge_requests/3
comments which seem to refer to it more generally. I guess this is because
I've never used gitlab and have no idea how to navigate my way round it.
The above URLs give me nothing when I use NetSurf. That probably shouldn't
surprise me, but is a pity given that they are about RO.
However I've also now been trying using FireFox (Linux) and that isn't much
better. I found *one* recent comment from ROOL giving reasons to reject
JB's changes which it refers to. But I can't find any of the other
discussions or comments people in this usenet thread seem to be referring
to. Tried clicking around various links, and I can find code, but not the
discussions. So if someone can point out how I do this I'd be grateful.
Steve Fryatt
Mar 14, 2021, 7:15:05 AM3/14/21
to
On 14 Mar, Jim Lesurf wrote in message
<590d043...@audiomisc.co.uk>:
> However I've also now been trying using FireFox (Linux) and that isn't
> much better. I found *one* recent comment from ROOL giving reasons to
> reject JB's changes which it refers to. But I can't find any of the other
> discussions or comments people in this usenet thread seem to be referring
> to.
I'm going by the comment made to JB, which references work done with CG to
improve the source tree for merging in 2018, as well as mentioning private
emails between ROOL and CG on the subject which ROOL suggest petered out
when ROOL didn't get answers to their messages.
Even from that one comment, there's clearly far more to this than you've
presented in your initial posts here.
> Tried clicking around various links, and I can find code, but not the
> discussions.
The other discussions look to be private (in emails?), as does a lot of the
older code (or it's well hidden in old branches and merge requests).
That's the main problem that I have with your accusations. If the code is
hidden, that's only because JB and CG have chosen not to put it into a
visible branch on ROOL's GitLab -- and that's their call, not ROOL's.
It might also explain the apparent problems merging. Generally, one branches
the code that one wants to work on through GitLab, works on that branch
locally and keeps it up to date with the changes to the "live" code as one
goes. In that scenario, one just needs to push one's local branch back to
GitLab occasionally for it to be safely backed-up on ROOL's server and
visible to everyone at no extra effort. And when one comes to create that
final merge-request, it's "just" a case of getting the branch fully
up-to-date with where the "live" code is now, and then presenting it to ROOL
for review.
If this isn't what has been done, then it could well be an utter nightmare
to merge back in -- which is what ROOL seem to be saying. The comment about
"a misunderstanding of how git can be used" seems to point this way, too.
When projects are moving fast and many people are contributing, it's very
easy to tie oneself up in knots if the source control tools aren't used in
the correct way. I've done this myself with both Subversion and Git, and
know from first-hand experience how painful it can be to sort out. Small,
quick changes can be done in an ad-hoc way without much pain; anything "big"
which affects multiple files or takes weeks or months to complete *must* be
done in a manageable way, with changes in the main source being kept on top
of regularly by merging them in.
If things are so out of kilter in the new USB code that unrelated stuff
removed by other developers in 2018 is reappearing in the 2021 merge
request, then the only people who can fix it are JB and CG. In the worst
case, it even may come down to creating a clean, new branch from HEAD and
transferring their changes across piece by piece (and yes, I've done this
before -- and learned my lesson as to why it's bad to get into this
situation).
It might be hard work for the people who wrote the new code -- but it will
be many times more difficult for ROOL, because ROOL aren't familiar with the
changes being applied.
As I've said before, the above is speculative -- based on ROOL's comment to
JB's merge request and my own experiences. I have no insider knowledge of
the situation, which is why I'd hoped that you could back up your own theory
as to what was stopping things.
<590d043...@audiomisc.co.uk>:
> However I've also now been trying using FireFox (Linux) and that isn't
> much better. I found *one* recent comment from ROOL giving reasons to
> reject JB's changes which it refers to. But I can't find any of the other
> discussions or comments people in this usenet thread seem to be referring
> to.
improve the source tree for merging in 2018, as well as mentioning private
emails between ROOL and CG on the subject which ROOL suggest petered out
when ROOL didn't get answers to their messages.
Even from that one comment, there's clearly far more to this than you've
presented in your initial posts here.
> Tried clicking around various links, and I can find code, but not the
> discussions.
older code (or it's well hidden in old branches and merge requests).
That's the main problem that I have with your accusations. If the code is
hidden, that's only because JB and CG have chosen not to put it into a
visible branch on ROOL's GitLab -- and that's their call, not ROOL's.
It might also explain the apparent problems merging. Generally, one branches
the code that one wants to work on through GitLab, works on that branch
locally and keeps it up to date with the changes to the "live" code as one
goes. In that scenario, one just needs to push one's local branch back to
GitLab occasionally for it to be safely backed-up on ROOL's server and
visible to everyone at no extra effort. And when one comes to create that
final merge-request, it's "just" a case of getting the branch fully
up-to-date with where the "live" code is now, and then presenting it to ROOL
for review.
If this isn't what has been done, then it could well be an utter nightmare
to merge back in -- which is what ROOL seem to be saying. The comment about
"a misunderstanding of how git can be used" seems to point this way, too.
When projects are moving fast and many people are contributing, it's very
easy to tie oneself up in knots if the source control tools aren't used in
the correct way. I've done this myself with both Subversion and Git, and
know from first-hand experience how painful it can be to sort out. Small,
quick changes can be done in an ad-hoc way without much pain; anything "big"
which affects multiple files or takes weeks or months to complete *must* be
done in a manageable way, with changes in the main source being kept on top
of regularly by merging them in.
If things are so out of kilter in the new USB code that unrelated stuff
removed by other developers in 2018 is reappearing in the 2021 merge
request, then the only people who can fix it are JB and CG. In the worst
case, it even may come down to creating a clean, new branch from HEAD and
transferring their changes across piece by piece (and yes, I've done this
before -- and learned my lesson as to why it's bad to get into this
situation).
It might be hard work for the people who wrote the new code -- but it will
be many times more difficult for ROOL, because ROOL aren't familiar with the
changes being applied.
As I've said before, the above is speculative -- based on ROOL's comment to
JB's merge request and my own experiences. I have no insider knowledge of
the situation, which is why I'd hoped that you could back up your own theory
as to what was stopping things.
Theo
Mar 14, 2021, 8:27:36 AM3/14/21
to
Jim Lesurf <no...@audiomisc.co.uk> wrote:
> Actually, I think it is *way* beyond my skillset to do so. But I
> understand that isn't a limit that applies to (many) others! :-)
Indeed, that's not a dig at you. Just means that all the information is out
> Actually, I think it is *way* beyond my skillset to do so. But I
> understand that isn't a limit that applies to (many) others! :-)
there if anyone with appropriate skills wishes to take it on. There aren't
any missing pieces of the puzzle (that we know about).
> I do note the other points you made in this posting and the following one.
> I'll see if I can find out more, elsewhere.
just appeared out of a hat. I haven't studied the ROOL forum in enough
detail to know.
> The question in my mind is: given what you have said, which RPis, etc, have
> this if the above was done? All? i.e. none have hardware that can't cope?
port on all Pis prior to the Pi4 (and the USB pins on the Pi4 power USB-C
port). I imagine some work would be needed on that, although the driver
code that I think RISC OS borrows from other platforms should support audio.
On the Pi4 the type-A ports (USB3 and USB2) are driven by a PCIe controller
chip which uses EHCIDriver for USB2 devices (as most sound devices are).
The second changeset addresses audio support in EHCIDriver so, if merged,
audio may work on those.
> Given also that Colin and John have been mentioned more than once, a more
> open question for people: Are there any other people who might be up for
> this sort of thing, and capable? Note that Jason T. is 32-bitting the ROSS
> and adding more capture/playout ability. Given that, the absence of
> USB Audio will seem even odder to people. Whereas up to now the 16bit
> limit of the ROSS has made good use of USB Audio problematic, as has the
> tendency to lack any reasonably audio capture as standard.
implausible. The changes don't look enormous, so it might be feasible to
manually reapply them to the current codebase. It's a bit frustrating that
the work Colin did appears to have gone missing, but it wouldn't be a huge
amount of work to reapply them. Somebody who isn't familiar with the code
can try merging them by rote, but won't be very able to deal with problems
if they don't work.
Although the other problem would be testing them, given we don't know what
kind of test setup John and Colin used, or what the limitations on supported
devices might be (beyond just plugging in a random USB audio device and
hoping it works). Many devices can be 'quirky' and it's good to test with a
device that plays it by the book. If audio works on the ARMX6 using a
non-mainline build then that platform and a known-working device would be a
good starting point.
Theo
Brian Jordan
Mar 14, 2021, 8:33:02 AM3/14/21