Raspberry Pi -A New DIY'ers Digital Hub? - Page 14 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Source

Digital Source Digital Players and Recorders: CD , SACD , Tape, Memory Card, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 18th January 2013, 04:28 PM   #131
diyAudio Member
 
Join Date: Mar 2002
Location: Glasgow
Quote:
Originally Posted by philpoole View Post
I haven't implemented DMA. I think it may be overkill, although I wonder if it will overcome this current issue I have.
If used correctly, DMA is a big win. It takes a lot of load off the processor and relaxes the interrupt latency requirements.

Here is an example of how I believe it's normally done. You set up two buffers in memory, and set the DMA controller up for linked transfers. The DMA controller dishes out one sample at a time to the SPI controller, and it does this with a hardware "interrupt" that has higher priority than any code on the system. When it has finished reading one buffer, it raises an interrupt to the OS (calling your audio driver) and immediately starts on the second one.

So, your driver code gets called "once per buffer full", and it has almost "one buffer's worth" of time to respond to the IRQ and fill the buffer up.

Without DMA, your driver code will get called once per sample, and you have one sample's worth of time to respond. (Maybe a little more, as some SPI controllers include a small FIFO.)

The clincher is that the response time includes the "interrupt latency": the time between the hardware asking for another sample, and the Linux kernel getting its act together to execute your driver code. I don't know much about the details of the Linux kernel, but I doubt it can reliably service an interrupt in one sample's worth of time.

So, to cut a long story short, DMA allows you to cope with worse interrupt latency (such as Linux has) without getting underruns, by just using bigger buffers.

You may think that if you just spin in a tight loop, polling the SPI controller, you won't miss any samples. But this is doomed to failure. The OS will swap your task out sooner or later, as it needs to get other stuff done. (maybe mpd needs to decode some more audio.)

The last project I worked on was an industrial ultrasound system handling 6 channels of data at 1MHz sampling rate. Without DMA and double buffering, it would simply never have worked.
__________________
'Like the thirteenth chime from a crazy clock which not only in itself fails to command belief but also casts a certain doubt upon the accuracy of the previous twelve strokes.'

Last edited by scopeboy; 18th January 2013 at 04:35 PM.
  Reply With Quote
Old 18th January 2013, 08:59 PM   #132
diyAudio Member
 
Join Date: Oct 2004
I'm aware of how DMAs work. I wrote a SB16 device driver for my degree, using DMAs.
My reluctance to start work on DMA, might be to do with needing a break, but also to understand what I currently have - and how it can be optimised. I'm not fully aware of how to implement an ALSA driver correctly. The ALSA documentation is a bit vague in places, so I'm not fully confident my implementation is the most efficient regarding the API.
Your description is a bit more loading than in the raspberry pi. For the pi, you receive an interrupt every 64 samples, not every individual sample. So although a little excessive, it's not as bad as you think.
With my current ALSA setup, the DMA could be interrupting every 2048 samples. An order of magnitude better than 64 samples, but not as good as DMA could be (e.g. 64k buffer's worth per interrupt, or more).
Having said all that. DMA will be free from interrupts, unlike the ARM, so hopefully will show some resilience (as long as there is always a spare DMA for this purpose, which may well be being used for USB HDD transfers).

I've been more interested recently in why my USB HDD (well, usb to sata hdd) is upsetting things - and why it's much better reading music files from SDHC.
Based on my keyboard incident I wondered if a better quality usb -> sata adaptor might improve things, or perhaps a very solid PSU, but it sounds like that may not be the case.
  Reply With Quote
Old 19th January 2013, 02:58 AM   #133
diyAudio Member
 
Join Date: Apr 2011
There are several ways one connected usb device can upset another usb device.

1. the two devices may share the same host controller and interrupts

2. a low or full speed device will render ALL devices connected to the same hub to enumerate at the lowest speed. (keyboards are low speed devices usually).

3. some usb device may reserve and hog a large nandwidth although it is not needed.

Alex
  Reply With Quote
Old 19th January 2013, 10:07 AM   #134
diyAudio Member
 
Join Date: Mar 2002
Location: Glasgow
Point 2 is wrong. You can plug any combination of devices into a USB 2.0 hub, and the high-speed ones will still get high speed.

What really happens is that the hub packages the low-speed transactions into its high-speed upstream connection. High-speed frames go by much faster than low-speed ones, so one low-speed transaction sometimes needs to be split across several high-speed frames. It's at this point that the Pi's USB controller drops the ball.

Philpoole: Do you know where this 64 sample figure comes from? Does the SPI controller have a 64 sample FIFO, or is there some DMA going on already?

I'm using a USB-SATA enclosure with a Jmicron chipset.
__________________
'Like the thirteenth chime from a crazy clock which not only in itself fails to command belief but also casts a certain doubt upon the accuracy of the previous twelve strokes.'

Last edited by scopeboy; 19th January 2013 at 10:11 AM.
  Reply With Quote
Old 19th January 2013, 01:13 PM   #135
diyAudio Member
 
Join Date: Apr 2011
I do not know about the specifics of the RPi. I was just listing various possible problems when you mix different speed USB devices.

For example, below is a comment from a user regarding a particular USB hub:


This review is from: D-Link DUB-H4 High Speed USB 2.0 4-Port Hub (Personal Computers)
I think the other reviews largely get it right. Two things I haven't seen in them, however: first, the plug on the power cord is in the shape of a wide black monolith, so, like bulky a/c adaptors... Second, the included documentation says that the hub will revert to a USB 1.1 hub FOR ALL DEVICES if you have any USB 1 device connected. It says that to get USB 2.0 throughput, you must disconnect all USB 1.0 or 1.1 devices from the hub first. That's worth knowing.

Finally, if you buy the hub, I suggest going to Windows Update and downloading the optional USB 2.0 fix for WinXP SP 1.
  Reply With Quote
Old 19th January 2013, 02:09 PM   #136
diyAudio Member
 
Join Date: Mar 2002
Location: Glasgow
There must be something wrong with that particular hub then, or the customer's OS. In general, you should be able to mix high-speed and full/low-speed devices on a USB 2.0 hub, and the high-speed devices should still run at high speed.
__________________
'Like the thirteenth chime from a crazy clock which not only in itself fails to command belief but also casts a certain doubt upon the accuracy of the previous twelve strokes.'
  Reply With Quote
Old 19th January 2013, 03:51 PM   #137
diyAudio Member
 
Join Date: Oct 2004
Quote:
Originally Posted by scopeboy View Post
Philpoole: Do you know where this 64 sample figure comes from? Does the SPI controller have a 64 sample FIFO, or is there some DMA going on already?

I'm using a USB-SATA enclosure with a Jmicron chipset.
I'm not using the SPI. The PCM I2S cell has a 64 sample FIFO.
  Reply With Quote
Old 19th January 2013, 08:49 PM   #138
diyAudio Member
 
Join Date: Mar 2002
Location: Glasgow
My bad... I got confused, SPI and I2S are kind of similar :-)

The FIFO will raise an interrupt when there are n samples left. What is n? Sometimes it's programmable.
__________________
'Like the thirteenth chime from a crazy clock which not only in itself fails to command belief but also casts a certain doubt upon the accuracy of the previous twelve strokes.'
  Reply With Quote
Old 19th January 2013, 09:09 PM   #139
diyAudio Member
 
Join Date: Oct 2004
It transpires that it interrupts on an empty FIFO, 16 left, 48 left, or if not full - depending how you set TXTHR.
  Reply With Quote
Old 20th January 2013, 07:50 AM   #140
diyAudio Member
 
Join Date: Oct 2004
Quote:
Originally Posted by scopeboy View Post
My bad... I got confused, SPI and I2S are kind of similar :-)
Are you thinking I2C and not I2S?
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Tractrix in 1*Pi and 2*Pi revintage Multi-Way 21 26th August 2011 09:37 PM
Headphone Hub?? baronofhell Headphone Systems 3 26th May 2007 12:37 PM
centering hub for cdpro skyraider Digital Source 0 1st July 2005 07:08 AM
what to do with that old lan hub karma Everything Else 25 27th May 2003 05:58 AM
Barcode around CD hub? Circlotron Digital Source 0 13th February 2003 12:34 AM


New To Site? Need Help?

All times are GMT. The time now is 05:50 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2