USB - the Elephant in our Room

[fredjam]

Dom Wrote:
isochronous transfers from webcams and audio devices for example ......

I like to share my experience here. I bought the Pi because I thought and still think the Pi is well suited to act as an high quality audio streamer. For that reason I reinstalled Raspbian today and the latest soft- and firmware (I did an rpi-update). As powersource I use an Ipad power supply. The Pi is running headless with ethernet connection to my NAS and USB connection to my 24 bits 96 khz capable DAC. To play music I use MPD (the music player daemon) via ALSA. I played 24 bit 96 khz flac files.
The first run configured MPD to 16 bits 44,1 khz. Without doubt the music sounds fine with good detail and without noticable distortion even at high volume. Cpu usage is relatively high (45%) because it has to reencode the hires file to 16 bits 44,1 khz.
The second run I congfigured MPD to 24 bits 44,1 khz. The same file sounds distorted. BUT A LOT BETTER than my previous experiment 1.5 months ago.
At the third run I played the flac file at the full 24 bits 96 khz. Well of course this sounds awfull.
So I think progress has been made and that is wonderful. I hope that further progress is possible and that the Pi will be the streamer I think it could be.
To avoid misunderstanding here. English is not my native language. I do not intend to sound pushy or ungrateful.

Well in a sense the pi is already this sort of streamer. I play 24bit 96k flac files all the time and I
play HD video with surround sound. All of these sound wonderful but of course I am playing
then through HDMI which maybe isn't what you want to achieve.

[obcd]

Indeed, this isn't what some people try to achive.
Pretty much all audio equipment I have in my house has an analog "line in" connection.
Using the Pi to give them access to my digital music collection is the goal.
So, we have the analog out of the Pi.
It's only 11 bit and it's output level is so low that all kind of background noise becomes hearable.
No problem, we can use an usb-audio adapter.
We have our elephant which makes buying such a device a hit or miss.
We can use the hdmi sound output.
For a headless device, we will need an expensive converter. It will no longer be a cheap solution.

So let's hope we will get a (cheap) codec expansion board for the rev. 2 board soon. At least it's possible now that the IIS lines are made available.

[johnvdenley]

I just found that a power surge socket I was using (with USB slots in the top) to power the Pi was somehow causing a problem which meant that the keyboard and mouse were not working, as soon as I swapped the power from the socket to my PC, or used an old blackberry charger it all worked fine again!!!

[lb]

obcd, have you tried the latest firmware and kernel? The output quality of the integrated analog output should be greatly improved! Usually, it shouldn't be a problem that the output is limited to about 11 bits - music doesn't have more than about 10 bits of dynamic range.

[W. H. Heydt]

For a headless device, we will need an expensive converter. It will no longer be a cheap solution.

How expensive is expensive? I'm using this:
http://www.monoprice.com/products/produ ... 1&format=2
HDMI-->VGA converter that provides separate audio connectors on the VGA side (I got it because I have a PS/2 & VGA KVM switch, but I don't use the sound side, rather, I run the sound out the 3.5mm audio jack).

There may be cheaper options...

[fredjam]

Indeed, this isn't what some people try to achive.
Pretty much all audio equipment I have in my house has an analog "line in" connection.
Using the Pi to give them access to my digital music collection is the goal.
So, we have the analog out of the Pi.
It's only 11 bit and it's output level is so low that all kind of background noise becomes hearable.
No problem, we can use an usb-audio adapter.
We have our elephant which makes buying such a device a hit or miss.
We can use the hdmi sound output.
For a headless device, we will need an expensive converter. It will no longer be a cheap solution.

So let's hope we will get a (cheap) codec expansion board for the rev. 2 board soon. At least it's possible now that the IIS lines are made available.

Well you can buy a HDMI to VGA+analogue audio converter for about 22GBP so this might be
another possible way to go. Or you can play music through HDMI and take the analogue out from the
TV to an audio amplifier.

[fredjam]

obcd, have you tried the latest firmware and kernel? The output quality of the integrated analog output should be greatly improved! Usually, it shouldn't be a problem that the output is limited to about 11 bits - music doesn't have more than about 10 bits of dynamic range.

Well your music might not have more than 11 bits of dynamic range. A symphony orchestra can
easily use the full 16 bit 106db range of a standard CD. 11 bits is analogue TV sound ie. noisy
and obselete.

[jbeale]

The 16-bit compact disc has a theoretical dynamic range of about 96 dB [11] (or about 98 dB for sinusoidal signals [...])
[11] Fries, Bruce; Marty Fries (2005). Digital Audio Essentials. O'Reilly Media. p. 147. ISBN 0-596-00856-2. "Digital audio at 16-bit resolution has a theoretical dynamic range of 96 dB, but the actual dynamic range is usually lower because of overhead from filters that are built into most audio systems." ... "Audio CDs achieve about a 90-dB signal-to-noise ratio."
http://en.wikipedia.org/wiki/Dynamic_range

[jamesh]

Can you take any specifically audio discussion to a different thread please!

[jbeale]

Sorry about the off-topic stuff. Back on-topic, can anyone with some insight have a look at the patch Dmitry just posted today, which adds a 2-10 microsecond delay at end of dwc_otg_hc_start_transfer, and appears to fix an ISOCHRONOUS problem. Does this tell us anything new about the USB system? Or was this behavior already known? Here is his post: http://www.raspberrypi.org/phpBB3/viewt ... 00#p178819

[lintweaker]

The latest raspbian image did improve things again although it seems hotpluging my USB2 audio device does not work. It's only detected at boot.

Are these options still valid?
sdhci-bcm2708.enable_llm=1 sdhci-bcm2708.sync_after_dma=0

Playing DSD files over USB now works much better but sound still keeps cutting out every few seconds indicating packet loss

[billb]

I've had my RPi a few days now. When using an old Dell USB keyboard with built-in hub, I've had problems with keys repeating and/or responding slowly. This seems to have been solved by connecting to a powered USB hub, though.

Also, I have a USB flash drive that causes the RPi to reset itself as soon as I plug it in, although it works OK if it's already plugged in when the RPi is turned on. Is this very unusual?

[dom]

Are these options still valid?
sdhci-bcm2708.enable_llm=1 sdhci-bcm2708.sync_after_dma=0

sdhci-bcm2708.enable_llm=1 is there by default, so is superfluous.
sdhci-bcm2708.sync_after_dma=0 is not a default, as it's not compatible with all sdcards. It may be worth enabling if it causes no problems.

[lintweaker]

Are these options still valid?
sdhci-bcm2708.enable_llm=1 sdhci-bcm2708.sync_after_dma=0

sdhci-bcm2708.enable_llm=1 is there by default, so is superfluous.
sdhci-bcm2708.sync_after_dma=0 is not a default, as it's not compatible with all sdcards. It may be worth enabling if it causes no problems.

Thanks, dma=0 seems to be holding on my current SD card. On a unrelated topic, just noticed this in kernel messages (does not seem to do any harm):

Code: Select all

[    0.802512] ------------[ cut here ]------------
[    0.802713] WARNING: at drivers/tty/serial/serial_core.c:402 uart_get_baud_rate+0xe8/0x150()
[    0.802925] Modules linked in:
[    0.803085] [<c0013e1c>] (unwind_backtrace+0x0/0xf0) from [<c0028e78>] (warn_slowpath_common+0x4c/0x64)
[    0.803355] [<c0028e78>] (warn_slowpath_common+0x4c/0x64) from [<c0028eac>] (warn_slowpath_null+0x1c/0x24)
[    0.803638] [<c0028eac>] (warn_slowpath_null+0x1c/0x24) from [<c021eadc>] (uart_get_baud_rate+0xe8/0x150)
[    0.803913] [<c021eadc>] (uart_get_baud_rate+0xe8/0x150) from [<c021f368>] (pl011_set_termios+0x48/0x2d8)
[    0.804186] [<c021f368>] (pl011_set_termios+0x48/0x2d8) from [<c021ce90>] (uart_set_options+0xcc/0x13c)
[    0.804454] [<c021ce90>] (uart_set_options+0xcc/0x13c) from [<c021e9e4>] (uart_poll_init+0xac/0xbc)
[    0.804727] [<c021e9e4>] (uart_poll_init+0xac/0xbc) from [<c02034d4>] (tty_find_polling_driver+0x10c/0x150)
[    0.805015] [<c02034d4>] (tty_find_polling_driver+0x10c/0x150) from [<c022059c>] (configure_kgdboc+0x110/0x1b0)
[    0.805308] [<c022059c>] (configure_kgdboc+0x110/0x1b0) from [<c0008554>] (do_one_initcall+0x100/0x168)
[    0.805593] [<c0008554>] (do_one_initcall+0x100/0x168) from [<c04c27e8>] (kernel_init+0x88/0x12c)
[    0.805865] [<c04c27e8>] (kernel_init+0x88/0x12c) from [<c000e930>] (kernel_thread_exit+0x0/0x8)
[    0.806177] ---[ end trace cf7245562a7785ac ]---
[    0.806333] Division by zero in kernel.
[    0.806500] [<c0013e1c>] (unwind_backtrace+0x0/0xf0) from [<c01dfab4>] (Ldiv0+0x8/0x10)
[    0.806753] [<c01dfab4>] (Ldiv0+0x8/0x10) from [<c021f388>] (pl011_set_termios+0x68/0x2d8)
[    0.807000] [<c021f388>] (pl011_set_termios+0x68/0x2d8) from [<c021ce90>] (uart_set_options+0xcc/0x13c)
[    0.807272] [<c021ce90>] (uart_set_options+0xcc/0x13c) from [<c021e9e4>] (uart_poll_init+0xac/0xbc)
[    0.807543] [<c021e9e4>] (uart_poll_init+0xac/0xbc) from [<c02034d4>] (tty_find_polling_driver+0x10c/0x150)
[    0.807829] [<c02034d4>] (tty_find_polling_driver+0x10c/0x150) from [<c022059c>] (configure_kgdboc+0x110/0x1b0)
[    0.808122] [<c022059c>] (configure_kgdboc+0x110/0x1b0) from [<c0008554>] (do_one_initcall+0x100/0x168)
[    0.808402] [<c0008554>] (do_one_initcall+0x100/0x168) from [<c04c27e8>] (kernel_init+0x88/0x12c)
[    0.808675] [<c04c27e8>] (kernel_init+0x88/0x12c) from [<c000e930>] (kernel_thread_exit+0x0/0x8)
[    0.808915] Division by zero in kernel.
[    0.809075] [<c0013e1c>] (unwind_backtrace+0x0/0xf0) from [<c01dfab4>] (Ldiv0+0x8/0x10)
[    0.809322] [<c01dfab4>] (Ldiv0+0x8/0x10) from [<c021b660>] (uart_update_timeout+0x44/0x54)
[    0.809571] [<c021b660>] (uart_update_timeout+0x44/0x54) from [<c021f3fc>] (pl011_set_termios+0xdc/0x2d8)
[    0.809847] [<c021f3fc>] (pl011_set_termios+0xdc/0x2d8) from [<c021ce90>] (uart_set_options+0xcc/0x13c)
[    0.818491] [<c021ce90>] (uart_set_options+0xcc/0x13c) from [<c021e9e4>] (uart_poll_init+0xac/0xbc)
[    0.827127] [<c021e9e4>] (uart_poll_init+0xac/0xbc) from [<c02034d4>] (tty_find_polling_driver+0x10c/0x150)
[    0.835888] [<c02034d4>] (tty_find_polling_driver+0x10c/0x150) from [<c022059c>] (configure_kgdboc+0x110/0x1b0)
[    0.844737] [<c022059c>] (configure_kgdboc+0x110/0x1b0) from [<c0008554>] (do_one_initcall+0x100/0x168)
[    0.853676] [<c0008554>] (do_one_initcall+0x100/0x168) from [<c04c27e8>] (kernel_init+0x88/0x12c)
[    0.862728] [<c04c27e8>] (kernel_init+0x88/0x12c) from [<c000e930>] (kernel_thread_exit+0x0/0x8)

[obcd]

The Pi rebooting when you connect an usb drive is not unusual.
The rev. 1 Pi's can only deliver 100mA trough their usb ports.
The rev. 2 Pi's have the usb polyfuses removed.
Connecting an usb device can cause a short voltage dip on the 5V that makes the Pi reboot.
Some power supplies can handle the situation better than others.

[DavidMS]

I would like to understand if the problem I am seeing with intermittent Wifi is related to the 'USB' problem.

Basically I have trouble reliably connecting to my RPi using Putty. If I keep trying without changing anything it usually connects after about the 3 goes, then work fine for about 5 minutes before dropping out, after which I am can usually re-connect again after a number attempts

I am running the latest 18-9 distribution, with the Wifi connected using a powered hub. If I connect using either-net everything is stable and the putty sessions do not drop-out. The wifi seems to work fine if I am using for the web or doing updates

I had the same problem with the earlier distributions and was hoping thing would be better but it seems not.

[MaxK1]

If you post details, maybe someone can help.
lsusb ,dmesg etc.

[DavidMS]

Sorry but I am going to need a bit of help on how I get at "lsusb ,dmesg" ?

[MaxK1]

Sorry but I am going to need a bit of help on how I get at "lsusb ,dmesg" ?

Login and type lsusb to get a list of all USB devices
issue whatever commands you normally use to fire up your wifi
when the wifi fails, type dmesg to see what the kernel has to say about your wifi device

[jbeale]

Many people probably already know this, but just FYI: a full-speed (12 Mbps) USB device does perform up to 20% better in transfer rate when overclocking the Pi.

I am using the Teensy 2.0 USB Serial-ACM Transmit Bandwidth Benchmark (Serial Abstract Control Mechanism)
http://www.pjrc.com/teensy/usb_serial.html
lsusb says "16c0:047a VOTI Teensy Serial"

The benchmark just sends serial message data from the Teensy 2 board (which is ATMEGA32U4 with built-in USB) as fast as the receiving unit will take. On my Windows boxes the result is around 900 kBps, so the Pi is always slower than that, but it does depend on the ARM clock speed as shown below:

Code: Select all

Stock, with RTL8188CUS USB WiFi running: 
  Speed 500.22 kbytes/sec
With no other USB device connected: 
 (stock)  700 MHz: 537.04 kbytes/sec (baseline)
 "modest" 800 MHz: 570.18 kbytes/sec +14% clock, +6.2% USB
 "medium" 900 MHz: 580.88 kbytes/sec +29% clock, +8.2% USB
 "high"   950 MHz: 629.17 kbytes/sec +36% clock, +17.2% USB
 "turbo" 1000 MHz: 639.17 kbytes/sec +43% clock, +19% USB (unstable)

[mar-co0711]

Hi all,

I build an own image for a WLAN-router (ARM 9xxx). It runs perfektly. Then I build an image for the Raspberry PI (ARM 1xxx /BCM...) with the identic packages. It also runs perfectly.

The problem is:
Using the router: I read serial data from USB with pythonscript (pyserial), it delivers in 30 min. 9MB data.
Using RasPi: I read serial data from USB with the same pythonscript (pyserial), it delivers in 30 min. only 3.5MB data.

What can be the reason ????

RasPi is a 700MHz system and the router is a 400MHz system. So normally the RasPi should deliver more datas in 30 min. then the router.

Thx for answer....

[obcd]

What device is connected to your usb port to collect serial data? What is de baudrate setting?
What is the interrupt rate you are getting? What kernel did you base your build on?

[MaxK1]

We are supposed to guess. I'm guessing it doesn't belong here.

[mar-co0711]

On both side its the same baudrate configuration. TX=115200 and RX=115200. And I always use the same device to sent data to my router or to the RasPi.
I connect the device with a RS232/USB-converter (FTDI). The device sent nonstop data and the ruoter or the RasPi read nonstop the data. So there is no interrupt in use.
Modell BCM2708
Firmware Version OpenWrt Attitude Adjustment r33276
Kernel Version3.3.8

Additional I try to flash the wheezy-raspbian Image, then I use the same pythonscript to read the serial data. The result is the same, the RasPi also deliver only 3.5MB data.

[MaxK1]

On both side its the same baudrate configuration. TX=115200 and RX=115200. And I always use the same device to sent data to my router or to the RasPi.
I connect the device with a RS232/USB-converter (FTDI). The device sent nonstop data and the ruoter or the RasPi read nonstop the data. So there is no interrupt in use.
Modell BCM2708
Firmware Version OpenWrt Attitude Adjustment r33276
Kernel Version3.3.8

Additional I try to flash the wheezy-raspbian Image, then I use the same pythonscript to read the serial data. The result is the same, the RasPi also deliver only 3.5MB data.

Please see the "READ ME Using the troubleshooting forum."