Pi sound

[Brian Jordan]

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
_____________________________________________________________________

[Richard Ashbery]

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

I doubt this is possible under RISC OS on the R-Pi. I stand to be
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]

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?

[Jim Lesurf]

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

[Brian Jordan]

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.

[druck]

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
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]

In article <590a78c747b...@btinternet.com>, Brian Jordan

<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
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]

Does the ROOL OS send sound via HDMI? if so, you can extract it from that
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]

In article <s27qbo$2nq$1...@dont-email.me>,
druck <ne...@druck.org.uk> wrote:

> 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.

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.

[1] DEll S2340L 1920 x 1080 16 million colours.

[druck]

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
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]

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

[Chris Newman]

In article <s28mmg$rn2$1...@dont-email.me>, druck <ne...@druck.org.uk> wrote:

My Pi4 has an audio out mini jack socket.
I bought a small power speaker on Amazon and stuck it in that. Works
quite well.

--
Chris Newman

[Steve Fryatt]

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/

[Jim Lesurf]

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.

[Jim Lesurf]

In article <s28mmg$rn2$1...@dont-email.me>, druck <ne...@druck.org.uk> wrote:

> 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.

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]

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:
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!

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?

Theo

[Jim Lesurf]

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:

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]

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:

...

> 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
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.

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.

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?

The USB 2 hardware is all the same across all the Pis (including the Pi 4,
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.

I think everything in theory can, and as there are examples of audio working
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!!

Understood. I'm just trying to channel your enthusiasm towards the right
targets...

Theo

[Steve Fryatt]

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.

[Jim Lesurf]

In article <mpro.qpvhts02...@stevefryatt.org.uk>, Steve Fryatt

<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
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]

In article <lqb*-HU...@news.chiark.greenend.org.uk>, Theo

<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
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

[Steve Fryatt]

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.

[Steve Fryatt]

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.

[Jim Lesurf]

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

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]

In article <mpro.qpwnlb02...@stevefryatt.org.uk>, Steve Fryatt

<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
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]

In article <kqb*aT...@news.chiark.greenend.org.uk>, Theo
<theom...@chiark.greenend.org.uk> wrote:

> 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
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]

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.

[Theo]

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
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.

I would hope there has been some mention of this work elsewhere, it hasn't
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?

The changeset doesn't apply any changes to DWCDriver which drives the USB2
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.

If you can find someone who is familiar with the RISC OS USB stack, it's not
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]

In article <s28mmg$rn2$1...@dont-email.me>,
druck <ne...@druck.org.uk> wrote:

[Snip]

> 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).

Thanks for this information - I didn't know about these things. I have
now purchased a small speaker and a HDMI audio extractor box and finally
am able to play my Maestro files. There's something reassuring about
hearing the WaveSynth-Beep when the computer starts too.

When I asked the original question I had no idea that it would open such
a big can of worms all of which is way above my pay grade. I hope the
discussion you are all having bears fruit.
B

[Jim Lesurf]

In article <mpro.qpyhei02...@stevefryatt.org.uk>, Steve Fryatt

<ne...@stevefryatt.org.uk> wrote:
> 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.

The obvious problem for me is that I can't know or comment on private
exchanges which excluded me.

[snip]

> 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.

About the only snippets I have managed to see - even with FF - seem to show
that John has done *something* quite recently. But I have no idea what
because I can't see much, and I don't understand what I *have* seen!

[snip]

> 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.

All I can say about that is that I find it depressing that *ROOL* haven't
given this much priority themselves *so far as I've been able to see.* It
still seems to be a "leave it to someone else" status.

Again, I can quite understand ROOL have limited time and money so can't
wave wands. But this has been lagging for *years* with the impression that
many are simply leaving it to someone else. Not being able to see the
details of what *has* been doing on doesn't help much with that.

I'm clearly not able to judge this in terms of the coding involved. I can
only observe as an outsider the lack of actual progress. Given ROOL's large
role in OS development, however, makes me feel they should have been been
giving this a higher priority.

[Jim Lesurf]

In article <kqb*nb...@news.chiark.greenend.org.uk>, Theo

<theom...@chiark.greenend.org.uk> wrote:

> 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.

With that, I can help. I have a number of USB Devices, from standard/common
to weird or fancy. And could get more. I can already say which items
currently work and which ones don't for a number of examples.

As a summary of that so far:

Devices like the Focusrite 2i2 (all generations) work fine as USB Audio
DACs and ADCs. These are examples of 'Class 2' devices.

At present I'd recommend the 2i2 3rd Gen as - regardless of what the makers
say - it worked/works "out of the box" here and gives excellent results.
Unsurprisingly it is a market leader in terms of sales.

Common 'Hi Fi' DACs like the CA DACMagic plus also work. (Class 2)

The old Behringer UCA202 and similar are 'Class 1'. They work, but give
poorer audio as they are less capable.

TBH now I've got !USBScopePlus working I can even say which ones deliver
the best quality results!

So far as I can tell, stereo devices which the makers say are 'USB Audio
Class 1 or 2 compliant" will work, with one rider. The unusual '3 byte
transfer' examples may NOT work. But these are rare and tend to be special
for one reason or another.

If anyone has a device already and a machine like the ARMX6 they can try
the software I've put up here

http://www.audiomisc.co.uk/software/index.html

and report what they get. Anyone developing can obviously also use it.

My programs all single-task as I'm clueless about the WIMP. However someone
else is doing Wimp versions and they should also be available soon. People
can then take their pick.

The main limit at present is that support is 2-channel max. So, mono or
stereo devices are fine. However most LPCM multichannel devices also
require control software and get us back into "Windows Drivers' territory,
which is another can of frogs entirely. Fortunately, most users won't need
more than 2 channel in/out, and surround playback tends to go via HDMI
anyway as it is more AV than audio.

[Jim Lesurf]

For info. Colin has said I can report this in case it helps others:


"It is unfortunate that John was using a version of Isochronous USB which
wasn't up to date. I have uploaded my version to gitlab, to keep it safe,
which is up to date with the rool version. The changes are to USBDriver,
EHCIDriver and DWCDriver and work with any device with EHCI and pi's. I've
tested on ArmX6, BeagleBoard, PandaBoard, PiB+ Pi4. If anyone wants to try
they can get a softload version (IsocUSB) from my ftpc website. Note an
update to the latest BSD USBStack will mean the EHCIDriver changes will
not be needed but that won't come without other major changes. Changes to
DWCDriver and USBDriver are needed regardless of BSD changes."


I'd (i.e. me, Jim, *not* Colin) be interested in hearing reports from users
of the non-ArmX6 machines wrt how that works with Class compliant USB
devices and my software. Use the email address on my webpages as per my sig
if you wish to contact me.

[Steve Fryatt]

On 14 Mar, Jim Lesurf wrote in message

<590d22d...@audiomisc.co.uk>:

> For info. Colin has said I can report this in case it helps others:

Thanks; it's useful to have some more details as to what has been happening.

> "It is unfortunate that John was using a version of Isochronous USB which
> wasn't up to date. I have uploaded my version to gitlab, to keep it safe,
> which is up to date with the rool version. The changes are to USBDriver,
> EHCIDriver and DWCDriver and work with any device with EHCI and pi's.

This doesn't seem to be obvious from a quick search of the site -- is there
a link? There's certainly nothing showing publicly on the USBDriver
component.

Has a merge been requested, and if so, what reason did ROOL give for not
proceeding? If they didn't give a reason, I assume that would have been
followed up?

[Jim Lesurf]

In article <mpro.qpz69b06...@stevefryatt.org.uk>, Steve Fryatt

<ne...@stevefryatt.org.uk> wrote:
> On 14 Mar, Jim Lesurf wrote in message <590d22d...@audiomisc.co.uk>:

> > For info. Colin has said I can report this in case it helps others:

> Thanks; it's useful to have some more details as to what has been
> happening.

> > "It is unfortunate that John was using a version of Isochronous USB
> > which wasn't up to date. I have uploaded my version to gitlab, to keep
> > it safe, which is up to date with the rool version. The changes are to
> > USBDriver, EHCIDriver and DWCDriver and work with any device with EHCI
> > and pi's.

> This doesn't seem to be obvious from a quick search of the site -- is
> there a link? There's certainly nothing showing publicly on the
> USBDriver component.

I'm not sure what you are asking, but is this the page in question?

http://ftpc.iconbar.com/usb/index.html

Or do you mean on gitlab? I seem to have trouble with that when using RO,
so can't comment on it at present.

> Has a merge been requested, and if so, what reason did ROOL give for not
> proceeding? If they didn't give a reason, I assume that would have been
> followed up?

TBH I think that Colin gave up on ROOL some time ago. But I've not asked
him about the above point, so am guessing.

[Theo]

Jim Lesurf <no...@audiomisc.co.uk> wrote:
> In article <mpro.qpz69b06...@stevefryatt.org.uk>, Steve Fryatt
> <ne...@stevefryatt.org.uk> wrote:
> > > "It is unfortunate that John was using a version of Isochronous USB
> > > which wasn't up to date. I have uploaded my version to gitlab, to keep
> > > it safe, which is up to date with the rool version. The changes are to
> > > USBDriver, EHCIDriver and DWCDriver and work with any device with EHCI
> > > and pi's.
>
> > This doesn't seem to be obvious from a quick search of the site -- is
> > there a link? There's certainly nothing showing publicly on the
> > USBDriver component.
>
> I'm not sure what you are asking, but is this the page in question?
>
> http://ftpc.iconbar.com/usb/index.html

That doesn't have any source code, just binaries.

> Or do you mean on gitlab? I seem to have trouble with that when using RO,
> so can't comment on it at present.

Colin's own gitlab page is private and has no associated repos:
https://gitlab.riscosopen.org/cgranville

so we're none the wiser as to where this update source is.

Theo

[Steve Fryatt]

On 15 Mar, Jim Lesurf wrote in message
<590d91b...@audiomisc.co.uk>:

> In article <mpro.qpz69b06...@stevefryatt.org.uk>, Steve Fryatt
> <ne...@stevefryatt.org.uk> wrote:
>
> > This doesn't seem to be obvious from a quick search of the site -- is
> > there a link? There's certainly nothing showing publicly on the
> > USBDriver component.
>
> I'm not sure what you are asking, but is this the page in question?
>
> http://ftpc.iconbar.com/usb/index.html
>
> Or do you mean on gitlab? I seem to have trouble with that when using RO,
> so can't comment on it at present.

I'm asking about the source, in Git, on GitLab. That is, what would be up
for inclusion in the OS were a merge to happen. For that, the pre-built
binaries on Colin's site aren't a lot of use.

> > Has a merge been requested, and if so, what reason did ROOL give for not
> > proceeding? If they didn't give a reason, I assume that would have been
> > followed up?
>
> TBH I think that Colin gave up on ROOL some time ago. But I've not asked
> him about the above point, so am guessing.

You've claimed several times in this thread (not to mention elsewhere) that
ROOL are the problem. It's a little surprising to now discover that you're
only "guessing" at this.

:-(

ROOL's notes to the recent merge request from John suggest that they were
sending emails about this back in 2018, which they claim ended with an email
from them apparently going unanswered. This implies that there must have
been something that they were working towards. Does the lack of response
indicate that Colin gave up?

If this is ever to move forward, then either John and Colin need to sort the
remaining problems out (assuming that it's in their gift to do so), or we
(in the sense of "people who /might/ be able to help") need to know exactly
what those problems are. Can you fill that missing information in? Armed
with that knowledge, it might be possible to make some suggestions as to how
to proceed -- or at least explain why things have stopped.

Oh, and the source code needs to be accessible, of course; whilst that's not
public, we're completely helpless.

[Jim Lesurf]

In article <mpro.qq1cpz02...@stevefryatt.org.uk>, Steve Fryatt

<ne...@stevefryatt.org.uk> wrote:
> On 15 Mar, Jim Lesurf wrote in message <590d91b...@audiomisc.co.uk>:

> > In article <mpro.qpz69b06...@stevefryatt.org.uk>, Steve
> > Fryatt <ne...@stevefryatt.org.uk> wrote:
> >
> > > This doesn't seem to be obvious from a quick search of the site --
> > > is there a link? There's certainly nothing showing publicly on the
> > > USBDriver component.
> >
> > I'm not sure what you are asking, but is this the page in question?
> >
> > http://ftpc.iconbar.com/usb/index.html
> >
> > Or do you mean on gitlab? I seem to have trouble with that when using
> > RO, so can't comment on it at present.

> I'm asking about the source, in Git, on GitLab. That is, what would be
> up for inclusion in the OS were a merge to happen. For that, the
> pre-built binaries on Colin's site aren't a lot of use.

All I can say now about that is that Colin has made this comment to me
re the gitlab sources:

] Search usbdriver, ehcidriver, dwcdriver in gitlab projects. click on my
] version and select isochronous branch. They do not have a merge request
] I don't expect them to be accepted.

] If they want any more details they can email me.

cf below.

> > > Has a merge been requested, and if so, what reason did ROOL give for
> > > not proceeding? If they didn't give a reason, I assume that would
> > > have been followed up?
> >
> > TBH I think that Colin gave up on ROOL some time ago. But I've not
> > asked him about the above point, so am guessing.

> You've claimed several times in this thread (not to mention elsewhere)
> that ROOL are the problem. It's a little surprising to now discover that
> you're only "guessing" at this.

My guess was wrt *Colin's* 'reasons'. I think his new comment may indicate
I was correct. Given that ROOL have dismissed, criticised, and ignored his
earlier work *AND* made *NO* progress THEMSELVES with this for a DECADE
I think I can understand his current feelings - as I guess they may be. So,
my 'guess' is that he feels they would simply repeat their past behaviour.

But Colin has now said he can be emailed about the matter. I have no idea
if he will reply, though. That's his business.

> :-(

> ROOL's notes to the recent merge request from John suggest that they
> were sending emails about this back in 2018, which they claim ended with
> an email from them apparently going unanswered. This implies that there
> must have been something that they were working towards. Does the lack
> of response indicate that Colin gave up?

My guess is that Colin has decided that trying to work with ROOL is more of
a bother than it is worth. But this *is* also a guess on my part. Based on
the feeling that the way he and his code was treated by ROOL in the past
would have annoyed me, if I'd have been in his shoes. Although it is indeed
way above my skills to judge the code beyond finding that in practice it
works very well.

And if I'm misrepresnting or misunderstanding, bear in my that I don't
matter. The problem, as I guess, is that ROOL's treatment has made Colin
decide that trying to work with them is a PITA. I can only be very thankful
it hasn't also entirely put him off doing any work on USB Audio.

> If this is ever to move forward, then either John and Colin need to sort
> the remaining problems out (assuming that it's in their gift to do so),
> or we (in the sense of "people who /might/ be able to help") need to
> know exactly what those problems are.

Erm, I'd suggest that ROOL's atitude and behaviour might also need to be
sorted out. I keep coming back to the stark difference:

1) John / Colin -> about a decade of useful access to USB Audio for those
able to get an OS version which includes it.

2) ROOL -> Rejected the above when offerred with critical comments and has
produced NO alternative that works and is in use.

As an aside, I do wonder what ROOL will do when Jason's work comes to fruit
and we have a more capable 32bit ROSS that can handle multiple inputs and
outputs, etc. Something that will make users cry out for better audio
devices... most of which these days are USB.

> Oh, and the source code needs to be accessible, of course; whilst that's
> not public, we're completely helpless.

Yes and no. Some of us can now use USB Audio quite nicely. Because we have
either had the support added by the people who supplied our machine, or -
now - by using Colin's softload. So maybe it is time for ROOL to reconsider
*its* approach both to Colin/John and its own assessment of the need for
USB Audio support. If ROOL want this maybe they should think about mending
*their* fences with others.

If I am making mistakes, then I apologise and accept I'm a dimwit, etc. But
the real problem here isn't me. I'm just one of the users who finds USB
Audio useful. If ROOL wants to work *constructively* with Colin/John on
this then maybe they should consider rethinking their attitude because ROOL
are the ones who still lack USB Audio having rejected it in the past, and
then gone no-where with it.

To start, a sensible email to Colin *might* help. I don't know though,
because I am genuinely guessing. I'm more interested in talking to him
about what he is happy to do when I ask for help. So far as USB Audio is
concerned *I* gave up on ROOL long ago as they plainly have taken no active
interest whilst it has taken over much of audio on other OSs. I really
would welcome being able to change my view on that in future because I can
at that time see a more positive stance from ROOL.

JIm

[Theo]

Jim Lesurf <no...@audiomisc.co.uk> wrote:
> All I can say now about that is that Colin has made this comment to me
> re the gitlab sources:
>
> ] Search usbdriver, ehcidriver, dwcdriver in gitlab projects. click on my
> ] version and select isochronous branch. They do not have a merge request
> ] I don't expect them to be accepted.
>
> ] If they want any more details they can email me.

Ah, thanks. Gitlab doesn't make it easy to find things unless you know what
you're looking for. I see them now:

https://gitlab.riscosopen.org/cgranville/USBDriver/-/tree/isochronous
https://gitlab.riscosopen.org/cgranville/EHCIDriver/-/tree/isochronous
https://gitlab.riscosopen.org/cgranville/DWCDriver/-/tree/isochronous

That does appear to be rebased off the head of the tree.

I think they could do with a little tidying up, but if they work they should
be mergeable. That's not ROOL's job (there's a few bits to tidy up before
they can hit the automatic merge button), but it wouldn't need a lot to get
them over the line.

Theo

[Stuart]

In article <kqb*NN...@news.chiark.greenend.org.uk>,

Theo <theom...@chiark.greenend.org.uk> wrote:
> I think they could do with a little tidying up, but if they work they
> should be mergeable. That's not ROOL's job (there's a few bits to tidy
> up before they can hit the automatic merge button), but it wouldn't need
> a lot to get them over the line.

Reading this thread, it seems to me we need a programmer, or team of
programmers, prepared to take the code prepared by amateur programmers,
whiuch works, (no disrepect to anyone here) and refine it to the standards
required by ROOL.

--
Stuart Winsor

Tools With A Mission
sending tools across the world
http://www.twam.co.uk/