[Alsa-user] Recording with Presonus AudioBox 1818VSL on Raspberry Pi 2

[cornicis <cor...@go...>]

Hi,

I'm trying to get a Presonus AudioBox 1818VSL to work on a Raspberry Pi
2 Model B V1.1. This sound interface works out of the box on both my
linux desktop and laptop running Arch Linux with a kernel version of
4.0.0 and 4.0.3.

The problem on the Raspberry is heavy noise on the recording channels.
In detail there are following issues:
- channels 1 to 7 have periodic noise with a length of around 50ms: the
first 15ms present a wave form followed by 35ms of noise. all channels
have synchronous windows.
- the 8th channel is generally silent

I recorded a sample by using which works on my other machines:
arecord -vvv --device=plughw:0,0 --format=S32_LE --rate=48000
--channels=8 --duration=1 --dump-hw-params

This is the output:
Recording WAVE 'test1818VSL.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Channels 8
HW Params of device "plughw:0,0":
--------------------
ACCESS:  MMAP_INTERLEAVED MMAP_NONINTERLEAVED MMAP_COMPLEX
RW_INTERLEAVED RW_NONINTERLEAVED
FORMAT:  S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE
S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE
MU_LAW A_LAW IMA_ADPCM S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE
U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE U18_3BE
SUBFORMAT:  STD
SAMPLE_BITS: [4 64]
FRAME_BITS: [4 640000]
CHANNELS: [1 10000]
RATE: [4000 4294967295)
PERIOD_TIME: [125 212291)
PERIOD_SIZE: (0 911782903)
PERIOD_BYTES: (0 4294967295)
PERIODS: (0 4294967295]
BUFFER_TIME: [1 4294967295]
BUFFER_SIZE: [1 1823559356]
BUFFER_BYTES: [1 4294967295]
TICK_TIME: ALL
--------------------
Plug PCM: Route conversion PCM (sformat=S32_LE)
  Transformation table:
    0 <- 0
    1 <- 1
    2 <- 2
    3 <- 3
    4 <- 4
    5 <- 5
    6 <- 6
    7 <- 7
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 8
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 18724
  period_size  : 4681
  period_time  : 97520
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 4681
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 18724
  silence_threshold: 0
  silence_size : 0
  boundary     : 1227096064
Slave: Hardware PCM card 0 'AudioBox 1818 VSL' device 0 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 14
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 18724
  period_size  : 4681
  period_time  : 97520
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 4681
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 18724
  silence_threshold: 0
  silence_size : 0
  boundary     : 1227096064
  appl_ptr     : 0
  hw_ptr       : 0
Max peak (37448 samples): 0x7fff0001 #################### 99%
Max peak (37448 samples): 0x7f000000 #################### 99%
Max peak (37448 samples): 0x7f00ffff #################### 99%
Max peak (37448 samples): 0x7f000000 #################### 99%
Max peak (37448 samples): 0x7f000000 #################### 99%
Max peak (37448 samples): 0x7f000000 #################### 99%
Max peak (37448 samples): 0x7f000000 #################### 99%
Max peak (37448 samples): 0x7f0010dc #################### 99%
Max peak (37448 samples): 0x7f000000 #################### 99%
Max peak (37448 samples): 0x7f000000 #################### 99%
Max peak (37448 samples): 0x7f000000 #################### 99%





You might spot a bit of actual guitar recording on the first channel.
http://www.file-upload.net/download-10634116/test1818VSL.wav.html

Here is my alsa-info.txt for system info:
http://www.alsa-project.org/db/?f=4f586c81b0f02b1de739ddd9774fa9bdfbedd144

I tried using options snd_usb_audio nrpacks=1, but alsa seems to ignore
it anyway.

I'm a bit helpless and don't know how to approach this problem. I tried
most of the formats, sample-rates, period-times, buffer-sizes etc., but
results didn't vary much. I'm led to the conclusion that the input
stream is interpreted falsely or there is a timing problem. But what may
cause this? The older kernel or the ARM architecture? But it would be
strange if I'm the only one with those issues...

I've got experience as a developer will actively take part in solving
this. I plan to compile the newest kernel and alsa next week, but maybe
you have more promising suggestions. Am I able to get a raw input stream
somehow?


Regards,
Daniel