Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1276 > unrolled thread

Sound hardware access for RO

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-11 12:18 +0000
    Re: Sound hardware access for RO Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-01-11 12:30 +0000
      Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-11 13:43 +0000
        Re: Sound hardware access for RO Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-01-11 22:35 +0000
          Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-12 10:08 +0000
            Re: Sound hardware access for RO Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-01-12 17:57 +0000
              Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-13 12:05 +0000
        Re: Sound hardware access for RO Roger Darlington <rogerarm@freeuk.com> - 2012-04-03 09:03 +0100
          Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-04-03 09:53 +0100
    Re: Sound hardware access for RO John Kortink <kortink@inter.nl.net> - 2012-01-11 14:10 +0100
      Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-11 15:13 +0000
        Re: Sound hardware access for RO Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-11 17:04 +0000
        Re: Sound hardware access for RO John Kortink <kortink@inter.nl.net> - 2012-01-11 19:58 +0100
      Re: Sound hardware access for RO "Ste (news)" <steve@revi11.plus.com> - 2012-01-15 17:14 +0000
        Re: Sound hardware access for RO Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-17 07:11 +0100
    Re: Sound hardware access for RO druck <news@druck.org.uk> - 2012-01-11 20:52 +0000
      Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-12 09:21 +0000
        Re: Sound hardware access for RO druck <news@druck.org.uk> - 2012-01-14 20:34 +0000
          Re: Sound hardware access for RO Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-15 05:19 +0100
            Re: Sound hardware access for RO druck <news@druck.org.uk> - 2012-01-15 12:30 +0000
              Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-15 13:38 +0000
                Re: Sound hardware access for RO druck <news@druck.org.uk> - 2012-01-17 23:38 +0000
                  Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-18 09:37 +0000
                    Re: Sound hardware access for RO Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-01-27 02:05 +0000
                      Re: Sound hardware access for RO Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-27 05:19 +0100
              Re: Sound hardware access for RO Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-15 15:57 +0100
                Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-15 17:30 +0000
                  Re: Sound hardware access for RO Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-17 07:22 +0100
                    Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-17 09:28 +0000
                    Re: Sound hardware access for RO Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-17 11:31 +0000
                      Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-17 12:34 +0000
              Re: Sound hardware access for RO Dave Higton <davehigton@dsl.pipex.com> - 2012-01-16 21:19 +0000
            Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-15 10:18 +0000
              Re: Sound hardware access for RO Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-15 16:18 +0100
                Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-15 17:39 +0000
          Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-15 10:01 +0000
    Re: Sound hardware access for RO Dave Higton <davehigton@dsl.pipex.com> - 2012-01-16 21:28 +0000
      Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-17 09:35 +0000
      Re: Sound hardware access for RO Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-17 11:37 +0000
        Re: Sound hardware access for RO davehigton <davehigton14@googlemail.com> - 2012-01-17 05:07 -0800
          Re: Sound hardware access for RO Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-17 16:46 +0000
            Re: Sound hardware access for RO Ron <beeb@woosh.co.nz> - 2012-01-18 11:22 +1300
              Re: Sound hardware access for RO Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-17 23:42 +0000
                Re: Sound hardware access for RO Ron <beeb@woosh.co.nz> - 2012-01-18 13:47 +1300
        Re: Sound hardware access for RO Jim Lesurf <jcgl@audiomisc.co.uk> - 2012-01-17 12:36 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1314

In article <jeugt8$gh9$1@dont-email.me>, druck <news@druck.org.uk> wrote:
> On 15/01/2012 04:19, Rick Murray wrote:
> > On 14/01/2012 21:34, druck wrote:
> >


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

[toc] | [prev] | [next] | [standalone]

#1353

On 15/01/2012 13:38, Jim Lesurf wrote:
> In article<jeugt8$gh9$1@dont-email.me>, druck<news@druck.org.uk>  wrote:
>> On 15/01/2012 04:19, Rick Murray wrote:
>>> On 14/01/2012 21:34, druck wrote:
>>>
>
>
>>> 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

[toc] | [prev] | [next] | [standalone]

#1363

In article <jf50q5$oeq$2@dont-email.me>, druck <news@druck.org.uk> wrote:
> On 15/01/2012 13:38, Jim Lesurf wrote:
> > In article<jeugt8$gh9$1@dont-email.me>, druck<news@druck.org.uk> 
> > wrote:
> >> On 15/01/2012 04:19, Rick Murray wrote:
> >>> On 14/01/2012 21:34, druck wrote:
> >>>
> >
> >
> >>> 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

[toc] | [prev] | [next] | [standalone]

#1429

Jim Lesurf <jcgl@audiomisc.co.uk> wrote:

> 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 newsreplyaaa@wingsandbeaks.org.uk replacing "aaa" by "284".  

[toc] | [prev] | [next] | [standalone]

#1430

On Fri, 27 Jan 2012 02:05:44 +0000, Jeremy Nicoll - news posts 
<jn.nntp.scrap007@wingsandbeaks.org.uk> wrote:

> > Some will use small iPlops
> What are they?

Shiny pieces of <cough><cough>...

:-D

Best wishes,

Rick.

-- 
Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1315

On Sun, 15 Jan 2012 12:30:31 +0000, druck <news@druck.org.uk> wrote:

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


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


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

[toc] | [prev] | [next] | [standalone]

#1320

In article <almarsoft.7324079975835647142@news.orange.fr>, Rick Murray
<heyrickmail-usenet@yahoo.co.uk> wrote:
> On Sun, 15 Jan 2012 12:30:31 +0000, druck <news@druck.org.uk> wrote:

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

[toc] | [prev] | [next] | [standalone]

#1333

On 15/01/2012 18:30, Jim Lesurf wrote:

> 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? ;-)

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!


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

[toc] | [prev] | [next] | [standalone]

#1335

In article <4f151393$0$2519$ba4acef3@reader.news.orange.fr>, Rick Murray
<heyrickmail-usenet@yahoo.co.uk> wrote:
> On 15/01/2012 18:30, Jim Lesurf wrote:

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

[toc] | [prev] | [next] | [standalone]

#1336

Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:
> On 15/01/2012 18:30, Jim Lesurf wrote:
> 
> > 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? ;-)

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

[toc] | [prev] | [next] | [standalone]

#1341

In article <gUj*hCvXt@news.chiark.greenend.org.uk>,
   Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
> Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:
> > On 15/01/2012 18:30, Jim Lesurf wrote:
> > 
> > > 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? ;-)

> It depends on:
> 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

[toc] | [prev] | [next] | [standalone]

#1329

In message <jeugt8$gh9$1@dont-email.me>
          druck <news@druck.org.uk> wrote:

> On 15/01/2012 04:19, Rick Murray wrote:
> 
> > 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

[toc] | [prev] | [next] | [standalone]

#1313

In article <4f1253d9$0$5678$ba4acef3@reader.news.orange.fr>, Rick Murray
<heyrickmail-usenet@yahoo.co.uk> wrote:
> On 14/01/2012 21:34, druck wrote:

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

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

[toc] | [prev] | [next] | [standalone]

#1317

On 15/01/2012 11:18, Jim Lesurf wrote:

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


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


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

[toc] | [prev] | [next] | [standalone]

#1321

In article <4f12ee54$0$2502$ba4acef3@reader.news.orange.fr>, Rick Murray
<heyrickmail-usenet@yahoo.co.uk> wrote:
> On 15/01/2012 11:18, Jim Lesurf wrote:


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

[toc] | [prev] | [next] | [standalone]

#1312

In article <jesosq$m25$1@dont-email.me>, druck <news@druck.org.uk> wrote:
> On 12/01/2012 09:21, Jim Lesurf wrote:
> >> 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." :-)


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

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

[toc] | [prev] | [next] | [standalone]

#1328

In message <524fdeb0d8jcgl@audiomisc.co.uk>
          Jim Lesurf <jcgl@audiomisc.co.uk> wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#1334

In article <f436a45252.davehigton@dsl.pipex.com>, Dave Higton
<davehigton@dsl.pipex.com> wrote:
> In message <524fdeb0d8jcgl@audiomisc.co.uk> Jim Lesurf
>           <jcgl@audiomisc.co.uk> wrote:


> 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

[toc] | [prev] | [next] | [standalone]

#1337

Dave Higton <davehigton@dsl.pipex.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#1338

On Jan 17, 11:37 am, Theo Markettos <theom
+n...@chiark.greenend.org.uk> wrote:
> Dave Higton <davehig...@dsl.pipex.com> wrote:
> > 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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.sys.acorn.programmer

csiph-web