Discussion:
Sound hardware access for RO
(too old to reply)
Jim Lesurf
2012-01-11 12:18:46 UTC
Permalink
The 'Prize' I tried offerring to encourage someone to impliment modern USB
sound 'card' support for RO has now lapsed. No-one applied to me for this,
so I had essentially zero feedback. The closest I got was some people
saying they also wanted to see this being done.

What do people think would be needed to get someone interested in doing
this, and obtaining a satisfactory result that can then be applied to the
various hardware systems people are - or intending to - working on having
RO run on?

Is the problem simply that no-one with an interest in RO thinks they are
able to do this? Or is it lack of money on offer? Or that no-one has any
interest in serious audio? Or... what?

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Alan Wrigley
2012-01-11 12:30:48 UTC
Permalink
Post by Jim Lesurf
The 'Prize' I tried offerring to encourage someone to impliment modern USB
sound 'card' support for RO has now lapsed.
Is the problem simply that no-one with an interest in RO thinks they are
able to do this? Or is it lack of money on offer? Or that no-one has any
interest in serious audio? Or... what?
Is ANYONE interested in serious audio these days?

Alan

PS I would be, but I have far too many other projects that need my time, and
my hi-fi system works.
--
RISC OS - you know it makes cents
Jim Lesurf
2012-01-11 13:43:06 UTC
Permalink
In article
Post by Alan Wrigley
Post by Jim Lesurf
The 'Prize' I tried offerring to encourage someone to impliment modern
USB sound 'card' support for RO has now lapsed.
Is the problem simply that no-one with an interest in RO thinks they
are able to do this? Or is it lack of money on offer? Or that no-one
has any interest in serious audio? Or... what?
Is ANYONE interested in serious audio these days?
I cartainly am. :-) And it seems clear from magazine sales and talking to
some makers, etc, so are a fair number of other people. However the market
is dividing into two categories.

1) users of iPlops and look-alikes and mobile 'mp3' players.

2) People who are introducing some form of 'media player' hardware into
decent audio systems.

Given the problems people can encounter with some 'computer' kit, and the
tendency for standard PCs <sic> to be over specced, noisy, have interrupted
or irregular data flow, etc, this seems a place were the smaller and
'lighter' systems that RO could run may have an attraction for a market
that is small as a percentage of the UK population, but quite big in terms
of how many people currently use RO.
Post by Alan Wrigley
Alan
PS I would be, but I have far too many other projects that need my time,
and my hi-fi system works.
So do mine. :-) But I did spend a fair bit of time and effort (and money)
on getting (Linux based) items into the audio systems I use that work well
enough for serious listening. The whole process made me think that a RO
based solution might prove very attractive to users not already committed.
But at present this is impossible due to a lack of the ability to drive
good quality USB DACs. And an advantage of the USB route is that it would
free RO from having to have a sound system that had to be adapted for each
different hardware platform.

FWIW I'm basing my views on more than my own experience. Since I've been
writing for HiFi News I've had various feedback from makers and users
interested in 'computer audio'. [1] But for whatever reasons, an almost
total lack of feedback from RO users/programmers. Hence my questions. I
wonder if those who do work on developing/porting RO have much of a view of
what might be possible here. Or if it is simply not something they could
do. To me, though, this seems like it could be am opportunity to gain a
niche that could be useful for RO and its users as well as music
enthusiasts.

Slainte,

Jim

[1] And also some work with makers under NDA related to kit that I'd love
to see based on RO.
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Jeremy Nicoll - news posts
2012-01-11 22:35:40 UTC
Permalink
Post by Jim Lesurf
1) users of iPlops and look-alikes and mobile 'mp3' players.
You do yourself no favours by descending to calling things silly names.
Post by Jim Lesurf
Given the problems people can encounter with some 'computer' kit, and the
tendency for standard PCs <sic>
What's the "sic" for?
Post by Jim Lesurf
So do mine. :-) But I did spend a fair bit of time and effort (and money)
on getting (Linux based) items into the audio systems I use that work well
enough for serious listening. The whole process made me think that a RO
based solution might prove very attractive to users not already committed.
But at present this is impossible due to a lack of the ability to drive
good quality USB DACs.
Why would someone interested in high-quality audio want to bring it into a
RO system, though? Why not use the USB DAC to take it into a more
mainstream OS where versatile audio tools already exist?
Post by Jim Lesurf
Or if it is simply not something they could do. To me, though, this seems
like it could be am opportunity to gain a niche that could be useful for
RO and its users as well as music enthusiasts.
I understand why you approach this from a RO point of view, but don't
understand why a music enthusiast would want RO.

What does RO bring to this that makes it worthwhile?

And note I mean the OS, not the GUI.
--
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to ***@wingsandbeaks.org.uk replacing "aaa" by "284".
Jim Lesurf
2012-01-12 10:08:22 UTC
Permalink
Post by Jeremy Nicoll - news posts
Post by Jim Lesurf
1) users of iPlops and look-alikes and mobile 'mp3' players.
You do yourself no favours by descending to calling things silly names.
Post by Jim Lesurf
Given the problems people can encounter with some 'computer' kit, and
the tendency for standard PCs <sic>
What's the "sic" for?
For the usual reason I thought would be obvious. That to most of the public
'PC' means a standard desktop/laptop playing the current version of Home of
Office Windows and its bundled apps. Combined with the variability in
actual performance of such systems that a simple two-letter acronym
conceals.
Post by Jeremy Nicoll - news posts
Post by Jim Lesurf
So do mine. :-) But I did spend a fair bit of time and effort (and
money) on getting (Linux based) items into the audio systems I use
that work well enough for serious listening. The whole process made me
think that a RO based solution might prove very attractive to users
not already committed. But at present this is impossible due to a lack
of the ability to drive good quality USB DACs.
Why would someone interested in high-quality audio want to bring it into
a RO system, though? Why not use the USB DAC to take it into a more
mainstream OS where versatile audio tools already exist?
You mean, why would anyone be interested in RO? Why should anyone bother
to see if we can expand the usefulness and possible user base?
Post by Jeremy Nicoll - news posts
Post by Jim Lesurf
Or if it is simply not something they could do. To me, though, this
seems like it could be am opportunity to gain a niche that could be
useful for RO and its users as well as music enthusiasts.
I understand why you approach this from a RO point of view, but don't
understand why a music enthusiast would want RO.
What does RO bring to this that makes it worthwhile?
There are a number of reasons I have in mind. None are killers in
isolation, but the overall picture seems to me more compelling in
potential. My own experience of using a 'PC' (actually three different
systems running various Linux disros that I've hacked about to a minimal
degree) - plus a lot of feedback from audio fans who get problems with
getting a satisfactory replay system lead me to the following.

Some reasons are primarily hardware, others 'software' (inc. exploiting the
way the OS works) Others a mix or more a matter of different approaches
like the RO preference for smaller and simpler task apps or lighter systems
in terms of mainsplug power.

A particular difficulty is the sheer variability (and closed detail) nature
of a lot of the 'PC' hardware on sale. So that when someone buys a machine,
even with pre-installed OS, etc, they have no idea if it will show detailed
problems that another machine with nominally the same OS and bundle would
not. This may not show up when using Word to write a letter. But it can and
does when it comes to something like playing out an audio stream. It seems
quite common in the PC biz to assume that "I can hear something" means
"sound works perfectly". But in reality, it doesn't. The closer
relationship and considered porting of RO to a select choice of hardware
may help avoid this *if* people take sound seriously in a way that many
mainstream PC makers fail.

Look at systems like BB, ARMini, and even Raspberry Pi in contast with
standard 'PC' hardware. For playing audio a small, low power, and
conventional HD based system can be an advantage. Easier to add to an
existing audio setup. Avoids unwanted background noise from fans, whirring
discs. Lower power consumption makes it easier to make decent PSUs to
avoid interference, loop injections, etc. The low cost of the base system
also can be an advantage for someone wanted to develop a solution (sorry
about that term) for others.

Having available single tasking if that suits a developer of some user
software. (Note that many of the commercial solutions these days do package
as what behaves like a single task, even if not being so as this makes use
by those who want a music player not a computer easier.) Having a system
that doesn't start off doing things like letting system houskeeping tasks
or screen dimming or even having some other process interrupt the audio or
overlay it with some other stream.

Yes, you can make a fine audio player based on Linux, Windows, or Macs, and
avoid the significant problems. But when I look at the systems I've tried,
and discuss this with other audio fans they often feel that something
simpler and lighter would do as well and be more convenient. One that might
work fine with a small low-power chipset and from a relatively small
capacity solid-state 'hard disc'. I use my systems with external storage
via USB HDs. But others would use net storage elsewhere, or other methods
as they prefer. So no need for a big 'hard disc' in the actual 'computer'
if the OS also has a small footprint.

Yes, there are simplified systems like Squeezeboxes, et al. But these
generally tie all but the most geeky into a 'take it or leave it' package.
Whereas with a system based more obviously on a more general OS with a GUI
and (desktop) filer available the user can adapt if they choose, install
alternative software, or change they way they use it *without* having to
know how to write programs or fiddle at a deep level.

Again, an example. If you use something like a Brennan or other device you
tend to end up being presented with how *it* decides to store and 'index'
the files. Wheras using a more 'computer' approach gives you more
individual flexibility. So a RO based system would give people a chance to
see alternatives to existing 'PC' or 'closed solution' products. Its called
competition and choice.

And why *not* have RO be able to do this so potential users can choose, and
we might expand the user base and range of uses? If we presume this is a
waste of time then that seems to me to be just like saying we shouldn't
bother with *any* more development as people can use Windows for all their
home uses.

FWIW In recent months I've been doing a fair bit of work on testing USB
DACs and during that I've had a chance to talk to a few people about this.
It may already be too late, but I do have a feeling that there is/has been
an opportunity here that fits fairly well with the light hardware and OS
footprint of RO as an overall package on the newer hardware that people are
looking at porting RO onto. Maybe I'm wrong. But unless someone produces a
way for the RO systems to drive the USB DACs we are never going to know
what was missed.

Alas, my skill is in being able to test the kit. I'm a hopeless programmer
when it comes to things like being able to write the USB interfacing
required. I can write programs that do things like measure replay timing
with resolution approaching parts-per-billion, and detect any missing,
garbled, or repeated sample values. But not make a RO system drive a USB
DAC. Hence my raising the idea that someone should consider this.

I'll stop rambling now. In the end people either have an interest in this,
or not. Although I'm happy to raise the profile of the topic I realise I'm
not likely to convince those who are happy with what is already on offer.

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Alan Wrigley
2012-01-12 17:57:30 UTC
Permalink
Post by Jim Lesurf
I'll stop rambling now. In the end people either have an interest in this,
or not. Although I'm happy to raise the profile of the topic I realise I'm
not likely to convince those who are happy with what is already on offer.
If I won the lottery and thus had a source of cash to buy my food and other
necessities I would be very happy to immerse myself in something like this,
and I suspect one or two other RO users would feel the same. 30-40 years ago
I built amplifiers, loudspeakers, guitar effects, even a digital piano, but
the irony of getting old is that while your brain generates better and
better ideas based on increased experience, you feel less and less inclined
to damage your health by working your balls off to implement them.

Alan
--
RISC OS - you know it makes cents
Jim Lesurf
2012-01-13 12:05:19 UTC
Permalink
In article
Post by Alan Wrigley
Post by Jim Lesurf
I'll stop rambling now. In the end people either have an interest in
this, or not. Although I'm happy to raise the profile of the topic I
realise I'm not likely to convince those who are happy with what is
already on offer.
If I won the lottery and thus had a source of cash to buy my food and
other necessities I would be very happy to immerse myself in something
like this, and I suspect one or two other RO users would feel the same.
30-40 years ago I built amplifiers, loudspeakers, guitar effects, even a
digital piano, but the irony of getting old is that while your brain
generates better and better ideas based on increased experience, you
feel less and less inclined to damage your health by working your balls
off to implement them.
I can sympathise with that! I'd be delighted to be able to write the
required USB software myself. But the reality is that I've never had the
level of skill and understanding of programming to be able to do so. So I'm
honest enough with myself to know I couldn't cope. However it does seem to
me that some people *are* still working at improving/porting/etc out of
interest, and have a much better skill set than mine. What I can't tell if
if none have the knowledge of the audio side and requirements, or have any
interest in that. Or if they haven't realised that it could be a useful
chance to extend the usefulness and user base for RO.

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Roger Darlington
2012-04-03 08:03:13 UTC
Permalink
Post by Jim Lesurf
So do mine. :-) But I did spend a fair bit of time and effort (and money)
on getting (Linux based) items into the audio systems I use that work well
enough for serious listening. The whole process made me think that a RO
based solution might prove very attractive to users not already committed.
But at present this is impossible due to a lack of the ability to drive
good quality USB DACs. And an advantage of the USB route is that it would
free RO from having to have a sound system that had to be adapted for each
different hardware platform.
I haven't looked at ICs since I retired from electronics design 10
years ago, but, rather than use a USB2 DAC, (and with the USB2 spec
being such a hash and mis-match) are there not any USB3 DAC ICs?

USB3 not only has the data rate suitable for modern computers, but is,
as I understand it, a much cleaner implementation of USB with far
less of all the exceptions and ifs that USB2 suffers so badly from.

So, why implement it in USB2 when everyone else is moving over to
USB3... Or Lightspeed?
--
Cheers
Roger
All who wander are not lost
Jim Lesurf
2012-04-03 08:53:01 UTC
Permalink
Post by Roger Darlington
Post by Jim Lesurf
So do mine. :-) But I did spend a fair bit of time and effort (and
money) on getting (Linux based) items into the audio systems I use
that work well enough for serious listening. The whole process made me
think that a RO based solution might prove very attractive to users
not already committed. But at present this is impossible due to a lack
of the ability to drive good quality USB DACs. And an advantage of the
USB route is that it would free RO from having to have a sound system
that had to be adapted for each different hardware platform.
I haven't looked at ICs since I retired from electronics design 10
years ago, but, rather than use a USB2 DAC, (and with the USB2 spec
being such a hash and mis-match) are there not any USB3 DAC ICs?
USB3 not only has the data rate suitable for modern computers, but is,
as I understand it, a much cleaner implementation of USB with far less
of all the exceptions and ifs that USB2 suffers so badly from.
So, why implement it in USB2 when everyone else is moving over to
USB3... Or Lightspeed?
I have no argument with that in theory. However the practical problem seems
to be that no-one seems willing and able to do either way for RO. That is
the factor that blocks progress on this front.

And IIUC the current situation is that the DACs tend to use USB2.

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
John Kortink
2012-01-11 13:10:58 UTC
Permalink
On Wed, 11 Jan 2012 12:18:46 +0000 (GMT), Jim Lesurf
Post by Jim Lesurf
The 'Prize' I tried offerring to encourage someone to impliment modern USB
sound 'card' support for RO has now lapsed. No-one applied to me for this,
so I had essentially zero feedback. The closest I got was some people
saying they also wanted to see this being done.
What do people think would be needed to get someone interested in doing
this, and obtaining a satisfactory result that can then be applied to the
various hardware systems people are - or intending to - working on having
RO run on?
Is the problem simply that no-one with an interest in RO thinks they are
able to do this? Or is it lack of money on offer? Or that no-one has any
interest in serious audio? Or... what?
The couple of times that I glanced at what is being offered
for what (a.k.a. RISC OS Open 'bounties'), it looked like a
joke to me.

Professionals could not work for more than one or two days
for that sort of money. Let alone weeks or months, which is
more realistic in many cases. So forget about the money being
a real incentive. To pick something up, you almost have to
want it yourself.

Also, the requirements are (let's put it nicely) 'lacking in
detail'. They leave the door wide open for discussions about
what 'finished' means.

Just my two cents.


John Kortink
--
Email : ***@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink
Jim Lesurf
2012-01-11 15:13:53 UTC
Permalink
Post by John Kortink
On Wed, 11 Jan 2012 12:18:46 +0000 (GMT), Jim Lesurf
Post by Jim Lesurf
The 'Prize' I tried offerring to encourage someone to impliment modern
USB sound 'card' support for RO has now lapsed. No-one applied to me
for this, so I had essentially zero feedback. The closest I got was
some people saying they also wanted to see this being done.
What do people think would be needed to get someone interested in doing
this, and obtaining a satisfactory result that can then be applied to
the various hardware systems people are - or intending to - working on
having RO run on?
Is the problem simply that no-one with an interest in RO thinks they
are able to do this? Or is it lack of money on offer? Or that no-one
has any interest in serious audio? Or... what?
The couple of times that I glanced at what is being offered for what
(a.k.a. RISC OS Open 'bounties'), it looked like a joke to me.
Professionals could not work for more than one or two days for that sort
of money.
Did you not read the webpage (or the article)? It did clearly say:

"... a cash 'prize' to be awarded to the first person or company
or group of persons who produces new software for RISC OS that satisfies
the following requirements. The Prize is for £300 pounds. This is not meant
to be a full payment as if the project were a commercial commission. It is
simply offered to attract interest in the challenge to produce a specific
useful item for RO users, and win the prize‘ as a public recognition."

So I did realise it would not attract anyone who simply wanted a paid job.

I then listed the requirements, etc. cf below.

I can understand that you (and others) will have no interest if your
only concern is being paid a professional rate. That is fair enough.
However my impression is that some other people work on RO for reasons
other than earning a weekly wage. And may do some work out of interest,
or challenge, or to aid the usefulness and useage of RO. Not all of
them may have realised that the modern USB DACs may be a neat way to
'abstract' good audio provision from the specific RO hardware.
Post by John Kortink
Also, the requirements are (let's put it nicely) 'lacking in detail'.
They leave the door wide open for discussions about what 'finished'
means.
Again, for the Prize that was explained in the webpage/article. Defined
in terms of the tasks a system would perform and how this would be
judged. However I can see that if someone is unfamiliar with the
operation of the relevant types of USB DAC, what is required may
be unclear. And if someone can't see any point in RO supporting modern
audio, I understand why they would not be interested.

But of course anyone who wanted to clarify could have contacted me.

Be interested to see what others think.

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Theo Markettos
2012-01-11 17:04:22 UTC
Permalink
Post by Jim Lesurf
Again, for the Prize that was explained in the webpage/article. Defined
in terms of the tasks a system would perform and how this would be
judged. However I can see that if someone is unfamiliar with the
operation of the relevant types of USB DAC, what is required may
be unclear. And if someone can't see any point in RO supporting modern
audio, I understand why they would not be interested.
My concern on seeing the initial advert is that the 'prize' is
all-or-nothing. To claim it, you have to do a substantial amount of work.
Not only that, but it's a competitive task - winner-takes-all. So, by
undertaking it, you take a risk that someone might pip you at the post. And
therefore you have to do your work in secret, and risk duplicating the work
of other people. That's not how open source development works these days...
commit early, commit often is the way it goes.

But the bottom line is there aren't enough developers with enough time.

Theo
John Kortink
2012-01-11 18:58:27 UTC
Permalink
On Wed, 11 Jan 2012 15:13:53 +0000 (GMT), Jim Lesurf
Post by Jim Lesurf
[..]
Did you not read the webpage (or the article)?
Yes, I did.
Post by Jim Lesurf
"... a cash 'prize' to be awarded to the first person or company
or group of persons who produces new software for RISC OS that satisfies
the following requirements. The Prize is for £300 pounds. This is not meant
to be a full payment as if the project were a commercial commission. It is
simply offered to attract interest in the challenge to produce a specific
useful item for RO users, and ?win the prize‘ as a public recognition."
So I did realise it would not attract anyone who simply wanted a paid job.
That makes two of us. But it hardly invalidates the point.
Post by Jim Lesurf
I then listed the requirements, etc. cf below.
I can understand that you (and others) will have no interest if your
only concern is being paid a professional rate. That is fair enough.
However my impression is that some other people work on RO for reasons
other than earning a weekly wage. And may do some work out of interest,
or challenge, or to aid the usefulness and useage of RO.
I'm not unfamiliar with the concept.
Post by Jim Lesurf
Not all of
them may have realised that the modern USB DACs may be a neat way to
'abstract' good audio provision from the specific RO hardware.
That's probably an understatement. Perhaps 2 out of 100 ?

I'd be one of them. I've actually looked into it in the
recent past (with the idea of creating my own player,
using an external DAC).
Post by Jim Lesurf
Post by John Kortink
Also, the requirements are (let's put it nicely) 'lacking in detail'.
They leave the door wide open for discussions about what 'finished'
means.
Again, for the Prize that was explained in the webpage/article. Defined
in terms of the tasks a system would perform and how this would be
judged. However I can see that if someone is unfamiliar with the
operation of the relevant types of USB DAC, what is required may
be unclear. And if someone can't see any point in RO supporting modern
audio, I understand why they would not be interested.
I don't think the specifics of the DACs are the major
concern in this sort of project. It's being able to
properly code a realtime process.
Post by Jim Lesurf
But of course anyone who wanted to clarify could have contacted me.
The lack of clarity is not only the reader's problem.
It's also yours. Re: what exactly is it that you want.

The presentation is a lot more convincing if you don't
leave open ends. Describe. What goes in, what goes out,
what happens in between (e.g. do you want to control or
read state). Don't consciously try to leave open ends
to appear flexible. Be specific.


John Kortink
--
Email : ***@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink
Ste (news)
2012-01-15 17:14:43 UTC
Permalink
Post by John Kortink
The couple of times that I glanced at what is being offered
for what (a.k.a. RISC OS Open 'bounties'), it looked like a
joke to me.
OK. So let's take this point by point...
Post by John Kortink
Professionals could not work for more than one or two days
for that sort of money.
Indeed. We at ROOL expect the same when we work professionally. That hasn't
stopped us putting at least a man year _each_ into ROOL for absolutely
nothing. Doing a tiny extra job on the side and actually getting a few
hundred quid for it looks bloody attractive compared to that!
Post by John Kortink
Let alone weeks or months, which is more realistic in many cases. So
forget about the money being a real incentive. To pick something up, you
almost have to want it yourself.
That's true. Or, if you're a wealthy benefactor who can't program, you need
to put your money where your mouth is and donate more to those bounties.

The list of bounties on the ROOL site, and the current size of each pot, is
an illustration of just how much that is happening and just how much spare
cash the existing community has to hand.

In summary, it underlines, in bold, full upper-case the point I and many
others have been saying for years: RISC OS is dead as a commercial market
for software developers. And without compelling software being developed,
the few existing users will drift away - we certainly won't attract many new
ones!

So something needs to happen to get more money into the RISC OS ecosystem
and channel most of that to the developers. Our bounty scheme isn't that
something; it's simply a barometer.
Post by John Kortink
Also, the requirements are (let's put it nicely) 'lacking in detail'. They
leave the door wide open for discussions about what 'finished' means.
It's a good job you put it nicely, because otherwise I'd've told you to
RTFM. ;) There are a few points to keep in mind here:

1. the description needs to be clear to the USERS so they can decide whether
they want to donate and how much it deserves

2. we don't want to spend the rest of our (unpaid) lives at ROOL writing
detailed requirements specifications, functional specifications,
architecture diagrams, proposed database schemas, washing your underware,
etc.

3. part of the work of doing half of these tasks is thinking about what's
involved. It'd take days/weeks for any of us at ROOL to get our heads
around some of them. So...

If you, as a developer, think something sounds like it might be the sort of
thing you'd be interested in and the bounty pot looks like it's enough to
get you off your arse then you get in touch.

Then and only then will we look into the fine detail of what that task needs
to include and agree the acceptance criteria between you and ROOL. This may
take both parties a reasonably amount of time/effort. So be it. If we can't
reach an agreement, then we go our separate ways. If we can agree, then
we'll also agree a deadline and mark that bounty as "claimed".

You work towards the acceptance criteria within the agreed timescales and
ROOL will make periodic assessments of your progress. If you're getting
close to the deadline and haven't finished, we can always extend it if we
think you're making the right kind of progress.

At any time, you can throw in the towel and say "sod it". We'll simply
re-open the bounty to other developers.
Post by John Kortink
Just my two cents.
If this was Apple, and we have a few billion quid in the bank, a market of
hundreds of thousands of users, a pool of tens of thousands of developers,
then yes, I'd probably agree with you. But I don't; we have to be a little
more pragmatic than that.

Thanks,

Steve
--
Steve Revill @ Home
Note: All opinions expressed herein are my own.
Rick Murray
2012-01-17 06:11:00 UTC
Permalink
washing your underware, etc.
ROTFLMAO. :-)
If you, as a developer, think something sounds like it might be the sort of
thing you'd be interested in and the bounty pot looks like it's enough to
get you off your arse then you get in touch.
I'm looking at the bounty page. Keyboard shortcuts in the filer -
expired - didn't anybody think to ask Thomas Olssen? I'm running
FilerPro (or is it ProFiler?) on my RiscPC (3.70). It's pretty nice indeed!
I can't think EDID support would be *that* hard to do, though on the
other hand fixing up the USB stack is waaaaay above my skill level!


Best wishes,

Rick.
druck
2012-01-11 20:52:15 UTC
Permalink
Post by Jim Lesurf
The 'Prize' I tried offerring to encourage someone to impliment modern USB
sound 'card' support for RO has now lapsed.
[Snip]
Post by Jim Lesurf
Is the problem simply that no-one with an interest in RO thinks they are
able to do this? Or is it lack of money on offer? Or that no-one has any
interest in serious audio? Or... what?
Where are all the RISC OS audio applications which would take advantage
of a sound card? I don't think I've got any audio applications which
were even ported to 32bit, so the hardware isn't going to do much.

---druck
Jim Lesurf
2012-01-12 09:21:09 UTC
Permalink
Post by druck
Post by Jim Lesurf
The 'Prize' I tried offerring to encourage someone to impliment modern
USB sound 'card' support for RO has now lapsed.
[Snip]
Post by Jim Lesurf
Is the problem simply that no-one with an interest in RO thinks they
are able to do this? Or is it lack of money on offer? Or that no-one
has any interest in serious audio? Or... what?
Where are all the RISC OS audio applications which would take advantage
of a sound card? I don't think I've got any audio applications which
were even ported to 32bit, so the hardware isn't going to do much.
Put that the other way around. Why would anyone consider writing a playing
application that can play out, say, 96k/24 bit flac files on RO if there is
no way to get that though the hardware to a DAC than can then replay this
with no loss of sample values, etc?

Am I wrong to think that writing such a player would be much simpler than
the task of implimenting the USB async/isochronous path? Either way, why
write such a player when it can't be used?

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
druck
2012-01-14 20:34:37 UTC
Permalink
Post by Jim Lesurf
Post by druck
Where are all the RISC OS audio applications which would take advantage
of a sound card? I don't think I've got any audio applications which
were even ported to 32bit, so the hardware isn't going to do much.
Put that the other way around. Why would anyone consider writing a playing
application that can play out, say, 96k/24 bit flac files on RO if there is
no way to get that though the hardware to a DAC than can then replay this
with no loss of sample values, etc?
Playback only is rather pointless, there are any number of devices which
can play such files. It would only be worthwhile the considerable effort
of writing drivers to run software that performs more sophisticated use
of the sound card, such as running audio creation or editing software.
But I doubt any RISC OS system has the horse power to deal with 96K/24
bit sound.
Post by Jim Lesurf
Am I wrong to think that writing such a player would be much simpler than
the task of implimenting the USB async/isochronous path? Either way, why
write such a player when it can't be used?
The simplest solution would be to play using an iPod. If you really want
to involve the computer, how about DNLA software control streaming it
from a storage device to a home theatre system.

---druck
Rick Murray
2012-01-15 04:19:40 UTC
Permalink
Post by druck
But I doubt any RISC OS system has the horse power to deal with 96K/24
bit sound.
?

A 200MHz ARM with 100MHz DSP (DM320 chip) is quite capable of 128K AAC
audio and 2500kbps H.263 video, playback or recording, in realtime,
while (slowly) running an OS for telnet access via ethernet.

A generic last-year Android mobile, running on 700MHz-1GHz, ought to
find D1 H.264 and XviD a breeze, while 800MHz up ought to get some
mileage out of HD XviD with software decode. Such phones are comparable
to the likes of RaspberryPi (which can do HD) and the Beagle.

If that is possible, I can't see 96K/24bit being *that* much of a
struggle, surely?
Post by druck
If you really want to involve the computer, how about DNLA software
To Jim: Please name our killer application.

I see it as a chicken and egg, for we *have* no killer audio playback
app because we have no killer audio DAC because... The thing is, a lot
is needed besides USB support. Application support to make best use of
the DAC, for instance.

I cannot comment more, I listen with ear buds to MP3s on my mobile, and
I've never owned a speaker larger than myself, so you're kinda talking
to the wrong guy. ;-)


Best wishes,

Rick.
druck
2012-01-15 12:30:31 UTC
Permalink
Post by Rick Murray
Post by druck
But I doubt any RISC OS system has the horse power to deal with 96K/24
bit sound.
?
A 200MHz ARM with 100MHz DSP (DM320 chip) is quite capable of 128K AAC
audio and 2500kbps H.263 video, playback or recording, in realtime,
while (slowly) running an OS for telnet access via ethernet.
Note the use of the DSP chip.
Post by Rick Murray
A generic last-year Android mobile, running on 700MHz-1GHz, ought to
find D1 H.264 and XviD a breeze, while 800MHz up ought to get some
mileage out of HD XviD with software decode. Such phones are comparable
to the likes of RaspberryPi (which can do HD) and the Beagle.
Again Andriod makes use of the on chip PowerVR DSP.
Post by Rick Murray
If that is possible, I can't see 96K/24bit being *that* much of a
struggle, surely?
On a machine without DSP such as the Iyonix, then it would be a struggle.

We'd need to see a significant number of people using a system with a
DSP on board, and any RISC OS software written to make use if it.

---druck
Jim Lesurf
2012-01-15 13:38:52 UTC
Permalink
Post by druck
Post by Rick Murray
If that is possible, I can't see 96K/24bit being *that* much of a
struggle, surely?
On a machine without DSP such as the Iyonix, then it would be a struggle.
For 96k/24 bit Wave? (Or other LPCM). How would lack of 'DSP' prevent data
transfer from LPCM files to something like a USB DAC?

Perhaps one reason no-one was interested is that they don't understand the
nature of the 'high resolution' market in stereo audio.

For serious domestic audio, people tend to use LPCM formats, not ones like
mp3 or AAC which discard details. Indeed, it would be weird to want 24 bit
resolution but employ a lossy format.

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
druck
2012-01-17 23:38:47 UTC
Permalink
Post by Jim Lesurf
Post by druck
Post by Rick Murray
If that is possible, I can't see 96K/24bit being *that* much of a
struggle, surely?
On a machine without DSP such as the Iyonix, then it would be a struggle.
For 96k/24 bit Wave? (Or other LPCM). How would lack of 'DSP' prevent data
transfer from LPCM files to something like a USB DAC?
The vast majority of audio likely to be used isn't nice simple raw data
streams, it's in a a lossy or lossless compressed format, and good luck
decoding them in software without a DSP.

---druck
Jim Lesurf
2012-01-18 09:37:35 UTC
Permalink
Post by druck
Post by Jim Lesurf
Post by druck
Post by Rick Murray
If that is possible, I can't see 96K/24bit being *that* much of a
struggle, surely?
On a machine without DSP such as the Iyonix, then it would be a struggle.
For 96k/24 bit Wave? (Or other LPCM). How would lack of 'DSP' prevent
data transfer from LPCM files to something like a USB DAC?
The vast majority of audio likely to be used isn't nice simple raw data
streams, it's in a a lossy or lossless compressed format, and good luck
decoding them in software without a DSP.
Afraid you are still missing the point I made earlier about the market.

The 'audio' market is fragmented. Some will use small iPlops and moble
phones and focus on highly compressed lossy formats. Others want good
results and use LPCM or formats like flac. The wish for good results and
LPCM 96/24 tend to go together. Would *anyone* want '96k/24bit mp3'? It is
almost a contradiction in terms so far as the audio markets are concerned.

Being able to use a 96k/24bit iso/asynch USB DAC isn't aimed at the "vast
majority". It would be for an influential (in 'fashion' and 'aspiration'
terms) group who tend to *prefer* the 'unusual' approach, and will spend
extra for it - once it is available and shown to work well.

And I find my Iyonix can play mp3 or flac OK. No hardware DSP in sight. So
I still find it hard to believe that no more modern RO hardware would cope.

There is a simply way for you back your assertion, though. Show us a RO
hardware system that can drive one of the iso/asynch USB DACs and I'll test
it. :-)

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Jeremy Nicoll - news posts
2012-01-27 02:05:44 UTC
Permalink
Post by Jim Lesurf
Some will use small iPlops
What are they?
--
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to ***@wingsandbeaks.org.uk replacing "aaa" by "284".
Rick Murray
2012-01-27 04:19:57 UTC
Permalink
On Fri, 27 Jan 2012 02:05:44 +0000, Jeremy Nicoll - news posts
Post by Jeremy Nicoll - news posts
Post by Jim Lesurf
Some will use small iPlops
What are they?
Shiny pieces of <cough><cough>...

:-D

Best wishes,

Rick.
--
Best wishes,

Rick.
Rick Murray
2012-01-15 14:57:10 UTC
Permalink
Post by druck
Note the use of the DSP chip.
Indeed, but what do you think pulls the data from SD/USB, part
decodes, and pushes into place ready for the DSP to do its magic? If
the ARM can keep up with 128k + 2500k + file overheads, I maintain
that 96k/24 shouldn't kill it.

If, and maybe I'm wrong here, we assume the data rate is 8 bit
samples, then 24 is three 8s, so 96x3 gives us a data rate of 288kbit
which ought to be uncompressed so require little further processing
(hence no DSP requirement).

In essence, an ARM can marshall 2628kbit of data in realtime for
video, but can't hack 288kbit of audio data? Doesn't sound right...
Post by druck
Again Andriod makes use of the on chip PowerVR DSP.
And so would RISC OS if it wants access to the nifty video
capabilities... however, remember what is responsible for getting the
data into the DSP in the first place.
Post by druck
On a machine without DSP such as the Iyonix, then it would be a struggle.
Really? 288kbit of raw data is too much to ask?


Best wishes,

Rick.
Jim Lesurf
2012-01-15 17:30:52 UTC
Permalink
Post by druck
Note the use of the DSP chip.
Indeed, but what do you think pulls the data from SD/USB, part decodes,
and pushes into place ready for the DSP to do its magic? If the ARM can
keep up with 128k + 2500k + file overheads, I maintain that 96k/24
shouldn't kill it.
If, and maybe I'm wrong here, we assume the data rate is 8 bit samples,
then 24 is three 8s, so 96x3 gives us a data rate of 288kbit which
ought to be uncompressed so require little further processing (hence no
DSP requirement).
FWIW The asynch/iso USB systems I've checked (e.g. Halide Bridge and Arcam
r-DAC) expect S24_3LE format. i.e. each 24 bit sample value sent as a 24
bit signed integer. (So packed with a byte of zeros.)

That comes out as a raw data rate of

96000 x 8 bytes per sec = 768,000 bytes/sec

if I've pushed the right buttons on my calculator.

(The '8' is for stereo of course.)

Now that is a lot of data, but I'm surprised if the USB wasn't able to cope
in *any* RO hardware.

Also, the iso/async DACs do the control. They ask the host machine to send
another batch of data as their buffer become empty enough to get another
batch, and so the transfer itself can be in moderately irregular bursts
with no effect on the actual output. The computer doesn't have to worry
about precise timing. And the USB is isolated in many DACs to break any
ground loops or rf crap.

So far as I know, no 'DSP' is needed - unless what was meant was some byte
shuffling from the file format into S24_3LE and then running out via the
USB buffering, etc.

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Rick Murray
2012-01-17 06:22:11 UTC
Permalink
Post by Jim Lesurf
That comes out as a raw data rate of
96000 x 8 bytes per sec = 768,000 bytes/sec
[...]
Post by Jim Lesurf
Now that is a lot of data, but I'm surprised if the USB wasn't able to cope
in *any* RO hardware.
Like I said earlier, a 200MHz ARM is happy writing 2628kbit of video
data to USB in realtime. Actually, I lie. Looking at the flashy light on
the USB stick, it does it in bursts every 8-12 seconds. This meaning if
a 200MHz ARM can burst it, a slower ARM ought to be capable of at least
streaming it...but I don't think this idea is going to be aimed at an
ARM610 RiscPC now, is it? ;-)

There's no reason on god's green earth why a RaspberryPi capable of HD
video generated in realtime (i.e. a game) cannot hack the data rate
we're asking. I'd also expect StrongARM and Iyonix to do it without
panic. I mean, that's not even going to max out a USB 1.1 device!
Post by Jim Lesurf
batch, and so the transfer itself can be in moderately irregular bursts
with no effect on the actual output.
Indeed. You can't expect USB to run with no interruptions whatsoever due
to the nature of how most computers work; even harddiscs sometimes pause
to recalibrate. So it's best to throw data in bunches and let buffering
even it out.


Best wishes,

Rick.
Jim Lesurf
2012-01-17 09:28:12 UTC
Permalink
Post by Rick Murray
That comes out as a raw data rate of 96000 x 8 bytes per sec = 768,000
bytes/sec
[...]
Now that is a lot of data, but I'm surprised if the USB wasn't able to
cope in *any* RO hardware.
Like I said earlier, a 200MHz ARM is happy writing 2628kbit of video
data to USB in realtime. Actually, I lie. Looking at the flashy light on
the USB stick, it does it in bursts every 8-12 seconds. This meaning if
a 200MHz ARM can burst it, a slower ARM ought to be capable of at least
streaming it...but I don't think this idea is going to be aimed at an
ARM610 RiscPC now, is it? ;-)
A 610 RPC isn't what I had in mind. ;->

My interest is in something that would work on things like a BB, ARMini, or
a Raspberry Pi. I'd also like it work on an Iyo as that seems as if it may
be feasible to me. The point of the USB route, though, is to make it as
'generic' as possible.

Maker's of USB DACs I have discussed them with are often keen that their
products be as 'generic' in their ability to work as they can. This shows
up in their being willing to help me check and debug problems with Linux
even though their main focus is on Windows and Mac. So a generic USB
iso/asynch should open up access to many good DACs for a range of hardware
for RO. How wide this would all be, I don't know. We will only know if and
when someone does it.

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Theo Markettos
2012-01-17 11:31:42 UTC
Permalink
Post by Rick Murray
Post by Jim Lesurf
That comes out as a raw data rate of
96000 x 8 bytes per sec = 768,000 bytes/sec
[...]
Post by Jim Lesurf
Now that is a lot of data, but I'm surprised if the USB wasn't able to
cope in *any* RO hardware.
Like I said earlier, a 200MHz ARM is happy writing 2628kbit of video
data to USB in realtime. Actually, I lie. Looking at the flashy light on
the USB stick, it does it in bursts every 8-12 seconds. This meaning if
a 200MHz ARM can burst it, a slower ARM ought to be capable of at least
streaming it...but I don't think this idea is going to be aimed at an
ARM610 RiscPC now, is it? ;-)
It depends on:
1. Software overheads
2. Burst size
3. Latency
4. Caches

But yes, I can't understand why 768KB/s is a 'large' number on modern
hardware (post-Iyonix). I know it has to go through the USB stack which
might not have optimal timing, but unless we're sending one word per
transfer (ie one interrupt latency per word, like the Acorn floppy
controller) bursting shouldn't be hard. After all, the slowest PCI express
is at 2.5Gbit/s and that's driveable by similar-era hardware. I hope all
the overheads aren't a factor of 1000...

Theo
Jim Lesurf
2012-01-17 12:34:18 UTC
Permalink
Post by Theo Markettos
Post by Rick Murray
Post by Jim Lesurf
That comes out as a raw data rate of
96000 x 8 bytes per sec = 768,000 bytes/sec
[...]
Post by Jim Lesurf
Now that is a lot of data, but I'm surprised if the USB wasn't able to
cope in *any* RO hardware.
Like I said earlier, a 200MHz ARM is happy writing 2628kbit of video
data to USB in realtime. Actually, I lie. Looking at the flashy light on
the USB stick, it does it in bursts every 8-12 seconds. This meaning if
a 200MHz ARM can burst it, a slower ARM ought to be capable of at least
streaming it...but I don't think this idea is going to be aimed at an
ARM610 RiscPC now, is it? ;-)
1. Software overheads
2. Burst size
3. Latency
4. Caches
With the iso/asynch DACs, the DAC itself takes responsibility for a lot of
the buffering, etc. So some irregularity in the time taken by the host to
respond doesn't matter. It just needs to send all the right data in the
right order, and keep up in the medium to long term with this.

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Dave Higton
2012-01-16 21:19:10 UTC
Permalink
Post by druck
Post by Rick Murray
If that is possible, I can't see 96K/24bit being *that* much of a
struggle, surely?
On a machine without DSP such as the Iyonix, then it would be a struggle.
We'd need to see a significant number of people using a system with a
DSP on board, and any RISC OS software written to make use if it.
The current generation of machines has a DSP on board, and a quite
fast ARM CPU too.

Dave
Jim Lesurf
2012-01-15 10:18:39 UTC
Permalink
Post by Rick Murray
Post by druck
But I doubt any RISC OS system has the horse power to deal with 96K/24
bit sound.
?
A 200MHz ARM with 100MHz DSP (DM320 chip) is quite capable of 128K AAC
audio and 2500kbps H.263 video, playback or recording, in realtime,
while (slowly) running an OS for telnet access via ethernet.
A generic last-year Android mobile, running on 700MHz-1GHz, ought to
find D1 H.264 and XviD a breeze, while 800MHz up ought to get some
mileage out of HD XviD with software decode. Such phones are comparable
to the likes of RaspberryPi (which can do HD) and the Beagle.
If that is possible, I can't see 96K/24bit being *that* much of a
struggle, surely?
Nor can I. The defeat seems to me to be in the attitude.

FWIW I've also had my Iyo playing various kinds of file. In terms of the OS
and app, this works OK. The problem is the limitations in the physical DAC
arrangements.
Post by Rick Murray
Post by druck
If you really want to involve the computer, how about DNLA software
To Jim: Please name our killer application.
I see it as a chicken and egg, for we *have* no killer audio playback
app because we have no killer audio DAC because...
Yes, that is how I view it at present. No one will think of using a RO
based system for serious audio because the DAC 'solutions' available have
been lousy. No one will spend time developing good playing apps capable of
handling, say, 96k/24bit flac if there is no sign of hardware that could
play that *as* 96k/24 without fouling it up.

So far as I can see this has little to do with anything inherent in RO as
an OS. But everything to do with the choice of hardware *and methods
implimented to drive it*. Right down to the bodged Iyonix hardware that
tries to play 44.1k at 48k, so mangles the result.

Yet the whole point of the iso/asynch USB DACs is that they take much of
the load of decent conversion away from the computer itself. And can do so
with a generic driving system that is openly defined. So once in place it
can be used for a range of DACs potentially using a range of RO hardware.
So a general solution rather than a case-by-case hack. I've now tested a
number of such DACs. The more of them I test, and the more people in HiFi
talk about them, the more this seems to me like an opportunity that will be
missed.

Unfortunately, I now think my initial suspicion that there is little
intersection between those who work on RO OS and apps and those with an
involvement in good audio look correct. This may be the result of the same
'loop' so that those with a more audio-focussed awareness have gone
elsewhere long ago.

However I do think the responses I've had here do clarify the lack of
interest people have in even looking seriously at this area. The base
problem is a presumption that it isn't even worth thinking about. This then
become the self-fulfilling loop you describe above.

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Rick Murray
2012-01-15 15:18:47 UTC
Permalink
Post by Jim Lesurf
Nor can I. The defeat seems to me to be in the attitude.
Seems that way. Too easy to say "nah, can't be done". Just imagine if
Acorn thought that way in the '80s and picked to make their new product
range using the 68000 or, god help us, x86?
Just think, today's smartphones would be twice the size, need a cooling
fan, and never manage a day's use without a recharge. ;-)
Post by Jim Lesurf
Right down to the bodged Iyonix hardware that tries to play 44.1k at
48k, so mangles the result.
Wait... what?!? WTF can't correctly play *standard* CD audio type data?
Post by Jim Lesurf
However I do think the responses I've had here do clarify the lack of
interest people have in even looking seriously at this area. The base
problem is a presumption that it isn't even worth thinking about. This then
become the self-fulfilling loop you describe above.
Maybe somebody ought to think of it in different terms. There is a
stereotypical depiction of a hi-fi enthusiast: gold plated plugs and
sockets, 'name' brand amplifiers, maybe even a valve amp for the rich
warm sounds that transistors can't quite manage.
The one thing in common is that this sort of kit isn't cheap. You wan't
keep an audio nut happy in Tesco.

So, consider. A RaspberryPi mounted in a rather more expensive *chrome*
box with USB port and gold-plated outputs. Inside, also, a DAC and some
nifty software. GPIO and HDMI used to provide a small colour LCD with
touchpanel (can't be hard to implement, look at half the mobiles around
these days). There's your custom audio playback solution that ought to
be able to cope with MP3, AAC, FLAC, raw PCM... indeed the only issue I
can see is getting it to work with "funny" disc formats (how does RISC
OS fare with ext volumes, or NTFS?). Price tag? Remember your target
market. Make sure that the chrome is very shiny. ;-)

Or are we content to let somebody else do it in a less shiny box and a
generic Linux build?


Best wishes,

Rick.
Jim Lesurf
2012-01-15 17:39:35 UTC
Permalink
Post by Rick Murray
Post by Jim Lesurf
Right down to the bodged Iyonix hardware that tries to play 44.1k at
48k, so mangles the result.
Wait... what?!? WTF can't correctly play *standard* CD audio type data?
Afraid not. The audio hardware of the Iyonix is 'hard wired' so the DAC
runs at 48k. If you set any other rate it plays out the data with an
interval of 1/48k between samples. When it keeps running out it just
'repeats' the last sample until it has some new ones 'arrive' from the
playing software. The result is a weird sort of phase-time modulation that
distorts the output.

If you play 48k 16 bit material it can work moderately well, albiet not the
highest of fi. But any other rate gets mangled. *Including* CDDA rate.

<sigh>

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Jim Lesurf
2012-01-15 10:01:14 UTC
Permalink
Post by druck
Post by Jim Lesurf
Post by druck
Where are all the RISC OS audio applications which would take
advantage of a sound card? I don't think I've got any audio
applications which were even ported to 32bit, so the hardware isn't
going to do much.
Put that the other way around. Why would anyone consider writing a
playing application that can play out, say, 96k/24 bit flac files on
RO if there is no way to get that though the hardware to a DAC than
can then replay this with no loss of sample values, etc?
Playback only is rather pointless, there are any number of devices which
can play such files.
I note your personal opinion. But it does look like a version of "RO is
pointless because everyone can use Windows." :-)
Post by druck
It would only be worthwhile the considerable effort of writing drivers
to run software that performs more sophisticated use of the sound card,
such as running audio creation or editing software. But I doubt any RISC
OS system has the horse power to deal with 96K/24 bit sound.
Again, your personal opinion of what is "worthwhile" is noted. However the
reality is that many people want to play music without wishing to create or
edit it.

I'm also puzzled by the idea that *no* RO hardware could drive out LPCM
96k/24bit via USB from a Wave file.
Post by druck
Post by Jim Lesurf
Am I wrong to think that writing such a player would be much simpler
than the task of implimenting the USB async/isochronous path? Either
way, why write such a player when it can't be used?
The simplest solution would be to play using an iPod. If you really want
to involve the computer, how about DNLA software control streaming it
from a storage device to a home theatre system.
Yes, just as many no doubt have found it simplest to give up using RO
entirely for various other reasons.

I must admit I have been surprised by the fairly negative tone of many of
the responses I've had. But this may explain the lack of response to the
specific issue. Maybe these days people have simply become habituated to
thinking "there is no point" when someone suggests a new avenue for RO use.

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Dave Higton
2012-01-16 21:28:39 UTC
Permalink
Post by Jim Lesurf
The 'Prize' I tried offerring to encourage someone to impliment modern USB
sound 'card' support for RO has now lapsed. No-one applied to me for this,
so I had essentially zero feedback. The closest I got was some people
saying they also wanted to see this being done.
What do people think would be needed to get someone interested in doing
this, and obtaining a satisfactory result that can then be applied to the
various hardware systems people are - or intending to - working on having
RO run on?
Is the problem simply that no-one with an interest in RO thinks they are
able to do this? Or is it lack of money on offer? Or that no-one has any
interest in serious audio? Or... what?
I've looked at the RISC OS USB stack a couple of times, one motive
being to get isochronous transfer mode going. However, I could
never find my way around the software. It's a sprawling mass of
disparate code, of a standard that would never pass any sort of
code review. The perfect maintenance nightmare.

There is one suggestion that I would make: collaboration. When
trying to solve problems like this, two brains will produce the
result in less than half the time; three in less than a third.

I realise that collaboration proportionally devalues any bounty,
but I can't imagine anyone working solely - or even mainly - to
win the bounty. All those of us who would undertake any task such
as this does it for the love of it. A bounty is just a nice bonus
at the end.

And if any more people would like to collaborate, my suggestion is
that the first part of the task would be to document how the stack
works, and add block comments into the code.

Just my view of things.

Dave
Jim Lesurf
2012-01-17 09:35:18 UTC
Permalink
There is one suggestion that I would make: collaboration. When trying
to solve problems like this, two brains will produce the result in less
than half the time; three in less than a third.
I realise that collaboration proportionally devalues any bounty, but I
can't imagine anyone working solely - or even mainly - to win the
bounty. All those of us who would undertake any task such as this does
it for the love of it. A bounty is just a nice bonus at the end.
And if any more people would like to collaborate, my suggestion is that
the first part of the task would be to document how the stack works, and
add block comments into the code.
Thanks for the above.

For my part I am quite willing to do work in areas like the following.

To test how hardware systems perform with USB DACs. Also to buy appropriate
hardware - e.g. and ARMini or BB - and see if I need to modify the hardware
in some ways to enable things to work. I do have a background in testing
audio hardware and in building it. And a knowledge of high quality audio
gear and its engineering needs. So I can look into some of the electronic
hardware aspects of these things. Where I am totally useless is in writing
the required firmware.

I have also given a small amount to ROOL, and intend to do so again. As
shown by the 'prize' offer I am also quite willing to put up some money to
help this along. But it does seem to me that the main problem is to have
some people with the necessary software skills be willing to work on this
because they feel it worthwhile as a challenge useful to a community they
wish to help and belong to.

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Theo Markettos
2012-01-17 11:37:14 UTC
Permalink
Post by Dave Higton
I realise that collaboration proportionally devalues any bounty,
but I can't imagine anyone working solely - or even mainly - to
win the bounty. All those of us who would undertake any task such
as this does it for the love of it. A bounty is just a nice bonus
at the end.
And if any more people would like to collaborate, my suggestion is
that the first part of the task would be to document how the stack
works, and add block comments into the code.
That sounds like a good idea. USB support is essentially a core function
these days: bringing up new boards increasingly depends on it. So that
documentation becomes useful in porting RISC OS to new platforms, as well as
the more specialised task of this particular niche.

Theo
davehigton
2012-01-17 13:07:30 UTC
Permalink
On Jan 17, 11:37 am, Theo Markettos <theom
Post by Dave Higton
I realise that collaboration proportionally devalues any bounty,
but I can't imagine anyone working solely - or even mainly - to
win the bounty.  All those of us who would undertake any task such
as this does it for the love of it.  A bounty is just a nice bonus
at the end.
And if any more people would like to collaborate, my suggestion is
that the first part of the task would be to document how the stack
works, and add block comments into the code.
That sounds like a good idea.  USB support is essentially a core function
these days: bringing up new boards increasingly depends on it.  So that
documentation becomes useful in porting RISC OS to new platforms, as well as
the more specialised task of this particular niche.
What would be the best format in which to document the stack? Is
there
any visual tool that might give a clearer view than a text document?

Dave
Theo Markettos
2012-01-17 16:46:54 UTC
Permalink
Post by davehigton
What would be the best format in which to document the stack? Is
there any visual tool that might give a clearer view than a text document?
I quite like wiki, because it's good for doing frequenct occasional changes.
You can make small amounts of progress whenever you have a spare 5 minutes
wherever you are, rather than having to sit down and commit documentation
with a version control system only on a machine that has the right files,
editor, VCS, etc. Obviously it's not so great for commenting source code.

I don't know if there's a nice graphical tool... there's Graphviz or
UML-based tools, but I haven't really played with them. Generic graphics
packages aren't ideal for this purpose, because a small change in structure
often requires a lot of rewiring by hand.

Theo
Ron
2012-01-17 22:22:05 UTC
Permalink
Post by Theo Markettos
Post by davehigton
What would be the best format in which to document the stack? Is
there any visual tool that might give a clearer view than a text document?
I quite like wiki, because it's good for doing frequenct occasional changes.
You can make small amounts of progress whenever you have a spare 5 minutes
wherever you are, rather than having to sit down and commit documentation
with a version control system only on a machine that has the right files,
editor, VCS, etc. Obviously it's not so great for commenting source code.
I don't know if there's a nice graphical tool... there's Graphviz or
UML-based tools, but I haven't really played with them. Generic graphics
packages aren't ideal for this purpose, because a small change in structure
often requires a lot of rewiring by hand.
Theo
I have seen Latex mentioned for this, I know no more about it.

Regarding USB stacks, I have been keeping an eye on plan9 and minix
sources.
Plan9 have had USB2.0 for a while now. I dont think minix has much
USB support yet.

Plan9 though unix based, has a simpler and smaller code size
than Linux, but there are headers/libraries not covered by Unixlib.
I have ported the plan9 make which handles any plan9 native Mkfiles
if the Linux ones aren't available.
I am attracted by the fact there is no Linux complexities like Dbus
and they dont use X11 display servers, in fact they dont even have
a Web browser yet.
There has been a few arm ports, but it has largely been 386 code,
so the asm libraries would need tuning in places I think.
It will only be a matter of time before a BB port is done.

Plan9 is used for OS educational purposes and may be helpful to learn
in parallel with RISC OS USB and if a relationship between the two
could be established, things like audio and Bluetooth stacks could
follow.


As a part-timer, I would be interested to hear from the more
experienced people on the matter.
Plan9 may even be the type of base to build a new RISCOS with
multicore support and new filing systems etc ?

Ron M.
Theo Markettos
2012-01-17 23:42:09 UTC
Permalink
Post by Ron
I have seen Latex mentioned for this, I know no more about it.
I do, I've written a 220 page document in it[1]. LaTeX is very good at
structuring your document, and applying consistency to that document (for
example, scaling all your hundreds of figures by the same proportion could
be a one-line change). But if you want to make things 'just so' it can
require a surprising amount of obscure code. There are some quite funky
addon packages for doing diagrams (see, for example, pp 57, 69, 71, 90 [fig
4.11], 108, 114, 135 and 147) in the below which were all written in code
and formatted by LaTeX rather than in a graphics package [readers may spot a
few Draw-prepared diagrams on other pages too].

[1] http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-811.pdf

But I've yet to find a nice package for abstract block diagram drawing
(where you want it to look nice but don't want to specify where everything
goes exactly). Some of the things on
http://www.texample.net/tikz/examples/
are getting there (note the full source code of each example is on its page -
nothing more bar standard LaTeX and the TikZ graphics library are required).
Post by Ron
Regarding USB stacks, I have been keeping an eye on plan9 and minix
sources.
Plan9 have had USB2.0 for a while now. I dont think minix has much
USB support yet.
With standards like USB there's a tradeoff between simplicity and device
support. For example, Simtec USB is a nice and simple implementation, but
it doesn't work with very much (and when it does it needs the 'quirks'
settings of OtherDevs to tell it how). Linux USB can drive a lot more, but
it has layer upon layer of support for different host controllers, different
protocols, broken devices, etc. You don't get one without the other.

Theo
Ron
2012-01-18 00:47:03 UTC
Permalink
Post by Theo Markettos
Post by Ron
I have seen Latex mentioned for this, I know no more about it.
I do, I've written a 220 page document in it[1]. LaTeX is very good at
structuring your document, and applying consistency to that document (for
example, scaling all your hundreds of figures by the same proportion could
be a one-line change). But if you want to make things 'just so' it can
require a surprising amount of obscure code. There are some quite funky
addon packages for doing diagrams (see, for example, pp 57, 69, 71, 90 [fig
4.11], 108, 114, 135 and 147) in the below which were all written in code
and formatted by LaTeX rather than in a graphics package [readers may spot a
few Draw-prepared diagrams on other pages too].
[1] http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-811.pdf
But I've yet to find a nice package for abstract block diagram drawing
(where you want it to look nice but don't want to specify where everything
goes exactly). Some of the things on
http://www.texample.net/tikz/examples/
are getting there (note the full source code of each example is on its page -
nothing more bar standard LaTeX and the TikZ graphics library are required).
Your pdf works better in PDF 3.02 than most doing similar things.
Exports to draw with images etc as well.
There are few odd characters appearing in bold, I have seen this on
other PDF's also. p156, 'R1 is 10' -the ohms has been lost.
I'm not sure exactly what you mean by abstract block diagram drawing,
but AppolloneusPDT had dynamic resizing/positioning capabilities.
I once emailed them and I think they would let someone take over the
code. I imagine it would be impressive on the BB or the Iyonix.

I guess Vector and it's layers could do a bit, and it is currently
maintained.

Ron M.
Jim Lesurf
2012-01-17 12:36:55 UTC
Permalink
Post by Theo Markettos
I realise that collaboration proportionally devalues any bounty, but I
can't imagine anyone working solely - or even mainly - to win the
bounty. All those of us who would undertake any task such as this
does it for the love of it. A bounty is just a nice bonus at the end.
And if any more people would like to collaborate, my suggestion is
that the first part of the task would be to document how the stack
works, and add block comments into the code.
That sounds like a good idea. USB support is essentially a core
function these days: bringing up new boards increasingly depends on it.
So that documentation becomes useful in porting RISC OS to new
platforms, as well as the more specialised task of this particular niche.
FWIW I'm quite willing to try and help with writing documentation. However
I do have a strength/weakness. I am clueless about the details of how the
USB should (or does) work. This is good in the sense that I'd be asking
idiot questions that - if I can understand the replies - could mean clearer
documentation. The snag is that I'd keep asking idiotic questions others
would have to answer in a way my feeble understanding could accept!

Slainte,

Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Loading...