[LAU] Sound Devices USBPre2, UAC2 status

Post by s***@free.fr
Hi,
Some old posts exist about the UAC2 support for the Sound Devices USBPre2 but some problem remains.
The current status is that this sound card is supported as a USB 1.1 card in high-speed mode.
But this card is not seen as a Usb Audio Class 2 on Linux. On Mac OS X this card is recognized as UAC2.
My principal problem is that the "device descriptor" provided by the card is always a USB1.1 class
There is two modes of boot for the card (pressing the "1" button, the card is in full speed mode, without pressing in UAC2 mode)
There is only one difference between these two modes in the lsusb -v : the "bInterval" go to 4 from 1.
http://lists.linuxaudio.org/pipermail/linux-audio-user/2011-October/081275.html

Ok, I reconnected without pressing "1".
Bus 002 Device 002: ID 0926:0202
bNumConfigurations 2

Strange, I have never 2 on bNumConfigurations ! Somebody can test it on its card ?
This is perhaps my problem, my card only provides one "Configuration Descriptor".
The second one is certainly the UAC2 "Configuration Descriptor".
The lsusb without 1 pressed : http://pastebin.com/8yjjASv7
The lsusb with 1 pressed : http://pastebin.com/pGFdjR4K
The usbmon trace of the insertion of the usbpre2 (without "1") : http://pastebin.com/pySC4Age
This sound card is great, it is very disappointing to not be able to used it with all functionnalities.
I search help in order to debug this problem.
I am devlopper, I can test kernel patches without problem.
Thank for any idea (or patch).
Olivier
_______________________________________________
Linux-audio-user mailing list
http://lists.linuxaudio.org/listinfo/linux-audio-user

I also own this interface, recently it has started to work in uac2 mode,
I still cant raise the samplerate, but it runs.. however, It still runs
alot better in uac1.. when in uac2 jack mysteriously shuts down for no
appearant reason. I run archlinux, allways uptodated with vanilla kernel.

This is when I connect it without pressing 1. eg, uac2
http://pastebin.com/BFJTwXnJ
And as with pressing 1. http://pastebin.com/ZJ1jbPUK

s***@free.fr

2013-01-07 19:25:29 UTC

----- Mail original -----

Envoyé: Lundi 7 Janvier 2013 18:27:42
Objet: Re: [LAU] Sound Devices USBPre2, UAC2 status
I also own this interface, recently it has started to work in uac2
mode,
I still cant raise the samplerate, but it runs.. however, It still
runs
alot better in uac1.. when in uac2 jack mysteriously shuts down for
no
appearant reason. I run archlinux, allways uptodated with vanilla
kernel.
This is when I connect it without pressing 1. eg, uac2
http://pastebin.com/BFJTwXnJ
And as with pressing 1. http://pastebin.com/ZJ1jbPUK

Hi,

In my understanding, you are not in UAC2 , you are in high-speed mode but the usb audio protocol remains UAC1.

In the kernel source in the file include/uapi/linux/usb/audio.h is defined two values:
/* bInterfaceProtocol values to denote the version of the standard used */
#define UAC_VERSION_1 0x00
#define UAC_VERSION_2 0x20

So if the card is in UAC2 , you should see bInterfaceProtocol at 32 (or 0x20)
By example, now the RME babyface is recognize as UAC2 device, you can view its "lsub -v" here : http://minilien.fr/a0m3kc

But for the usbPre2 device with ou without pressing the "1" button, we have bInterfaceProtocol = 0. So we stays in UAC1, even the speed increase to high-speed.

So IMHO, it's why, we are already limited to 48khz framerate.

If a usb audio guru can confirm my idea...

I have no problem in high speed since kernel 3.2. Ubuntu kernel or vanilla kernel are OK (today, I use a 3.7.1 vanilla kernel).

Hans Wilmers

2013-01-10 12:23:57 UTC

Post by s***@free.fr
----- Mail original -----

Hi,
In my understanding, you are not in UAC2 , you are in high-speed mode but the usb audio protocol remains UAC1.
/* bInterfaceProtocol values to denote the version of the standard used */
#define UAC_VERSION_1 0x00
#define UAC_VERSION_2 0x20
So if the card is in UAC2 , you should see bInterfaceProtocol at 32 (or 0x20)
By example, now the RME babyface is recognize as UAC2 device, you can view its "lsub -v" here : http://minilien.fr/a0m3kc
But for the usbPre2 device with ou without pressing the "1" button, we have bInterfaceProtocol = 0. So we stays in UAC1, even the speed increase to high-speed.

I was also surprised to see that the USBPre2 now works duplex without
pressing the "1" button while connecting.

This was tested on Fedora 17 with stock kernel 3.6.6-1.fc17.
Jack was set to 512 Frames/period and 3 periods/buffer, and in a 24h
recording I got no xruns.
I did not manage to choose a sample rate unlike 48000, though.

With lsusb, I can see 2 configurations for the same device, and the
second one has bInterfaceProtocol = 32 for all interfaces except HID:
http://pastebin.com/zwq0VVbM

/ Hans

s***@free.fr

2013-01-10 17:08:56 UTC

----- Mail original -----

Envoyé: Jeudi 10 Janvier 2013 13:23:57
Objet: Re: [LAU] Sound Devices USBPre2, UAC2 status

Post by s***@free.fr
----- Mail original -----

Envoyé: Lundi 7 Janvier 2013 18:27:42
Objet: Re: [LAU] Sound Devices USBPre2, UAC2 status
I also own this interface, recently it has started to work in uac2
mode,
I still cant raise the samplerate, but it runs.. however, It still
runs
alot better in uac1.. when in uac2 jack mysteriously shuts down
for
no
appearant reason. I run archlinux, allways uptodated with vanilla
kernel.
This is when I connect it without pressing 1. eg, uac2
http://pastebin.com/BFJTwXnJ
And as with pressing 1. http://pastebin.com/ZJ1jbPUK

Hi,
In my understanding, you are not in UAC2 , you are in high-speed
mode but the usb audio protocol remains UAC1.
In the kernel source in the file include/uapi/linux/usb/audio.h is
/* bInterfaceProtocol values to denote the version of the standard
used */
#define UAC_VERSION_1 0x00
#define UAC_VERSION_2 0x20
So if the card is in UAC2 , you should see bInterfaceProtocol at 32
(or 0x20)
By example, now the RME babyface is recognize as UAC2 device, you
can view its "lsub -v" here : http://minilien.fr/a0m3kc
But for the usbPre2 device with ou without pressing the "1" button,
we have bInterfaceProtocol = 0. So we stays in UAC1, even the
speed increase to high-speed.

I was also surprised to see that the USBPre2 now works duplex without
pressing the "1" button while connecting.
This was tested on Fedora 17 with stock kernel 3.6.6-1.fc17.
Jack was set to 512 Frames/period and 3 periods/buffer, and in a 24h
recording I got no xruns.
I did not manage to choose a sample rate unlike 48000, though.
With lsusb, I can see 2 configurations for the same device, and the
http://pastebin.com/zwq0VVbM

Hi Hans,

Thank you for provided information.

So, some usbPre2 have bNumConfigurations=2 when "1" is not pressed but not all usbPre2 (mine or alexander devices have only one "Configuration Descriptor"). Your device descriptor contains a UAC2 configuration descriptor, This sound good.

Perhaps there is different firmware ?
I have the 1.03 firmware. Can you provide your firmware level ?
Can you test 192khz value in jackd ?

Olivier

Hans Wilmers

2013-01-10 21:10:41 UTC

Post by s***@free.fr
----- Mail original -----

Envoyé: Jeudi 10 Janvier 2013 13:23:57
Objet: Re: [LAU] Sound Devices USBPre2, UAC2 status

Post by s***@free.fr
----- Mail original -----

Envoyé: Lundi 7 Janvier 2013 18:27:42
Objet: Re: [LAU] Sound Devices USBPre2, UAC2 status
I also own this interface, recently it has started to work in uac2
mode,
I still cant raise the samplerate, but it runs.. however, It still
runs
alot better in uac1.. when in uac2 jack mysteriously shuts down
for
no
appearant reason. I run archlinux, allways uptodated with vanilla
kernel.
This is when I connect it without pressing 1. eg, uac2
http://pastebin.com/BFJTwXnJ
And as with pressing 1. http://pastebin.com/ZJ1jbPUK

Hi,
In my understanding, you are not in UAC2 , you are in high-speed
mode but the usb audio protocol remains UAC1.
In the kernel source in the file include/uapi/linux/usb/audio.h is
/* bInterfaceProtocol values to denote the version of the standard
used */
#define UAC_VERSION_1 0x00
#define UAC_VERSION_2 0x20
So if the card is in UAC2 , you should see bInterfaceProtocol at 32
(or 0x20)
By example, now the RME babyface is recognize as UAC2 device, you
can view its "lsub -v" here : http://minilien.fr/a0m3kc
But for the usbPre2 device with ou without pressing the "1" button,
we have bInterfaceProtocol = 0. So we stays in UAC1, even the
speed increase to high-speed.

I was also surprised to see that the USBPre2 now works duplex without
pressing the "1" button while connecting.
This was tested on Fedora 17 with stock kernel 3.6.6-1.fc17.
Jack was set to 512 Frames/period and 3 periods/buffer, and in a 24h
recording I got no xruns.
I did not manage to choose a sample rate unlike 48000, though.
With lsusb, I can see 2 configurations for the same device, and the
http://pastebin.com/zwq0VVbM

Hi Hans,
Thank you for provided information.
So, some usbPre2 have bNumConfigurations=2 when "1" is not pressed but not all usbPre2 (mine or alexander devices have only one "Configuration Descriptor"). Your device descriptor contains a UAC2 configuration descriptor, This sound good.
Perhaps there is different firmware ?
I have the 1.03 firmware. Can you provide your firmware level ?

Hmmm, same firmware 1.03 version here.
Which kernel are you running?

Post by s***@free.fr
Can you test 192khz value in jackd ?

No luck with this either - fastest one I get is 48000. This corresponds
to the output of lsusb, which does not list samplerates over 48000 for
this device.

/ Hans

s***@free.fr

2013-01-10 21:30:40 UTC

----- Mail original -----

Envoyé: Jeudi 10 Janvier 2013 22:10:41
Objet: Re: [LAU] Sound Devices USBPre2, UAC2 status

Post by s***@free.fr
----- Mail original -----

Envoyé: Jeudi 10 Janvier 2013 13:23:57
Objet: Re: [LAU] Sound Devices USBPre2, UAC2 status

Post by s***@free.fr
----- Mail original -----

Envoyé: Lundi 7 Janvier 2013 18:27:42
Objet: Re: [LAU] Sound Devices USBPre2, UAC2 status
I also own this interface, recently it has started to work in
uac2
mode,
I still cant raise the samplerate, but it runs.. however, It
still
runs
alot better in uac1.. when in uac2 jack mysteriously shuts down
for
no
appearant reason. I run archlinux, allways uptodated with
vanilla
kernel.
This is when I connect it without pressing 1. eg, uac2
http://pastebin.com/BFJTwXnJ
And as with pressing 1. http://pastebin.com/ZJ1jbPUK

Hi,
In my understanding, you are not in UAC2 , you are in high-speed
mode but the usb audio protocol remains UAC1.
In the kernel source in the file include/uapi/linux/usb/audio.h
is
/* bInterfaceProtocol values to denote the version of the
standard
used */
#define UAC_VERSION_1 0x00
#define UAC_VERSION_2 0x20
So if the card is in UAC2 , you should see bInterfaceProtocol at
32
(or 0x20)
By example, now the RME babyface is recognize as UAC2 device, you
can view its "lsub -v" here : http://minilien.fr/a0m3kc
But for the usbPre2 device with ou without pressing the "1"
button,
we have bInterfaceProtocol = 0. So we stays in UAC1, even the
speed increase to high-speed.

I was also surprised to see that the USBPre2 now works duplex
without
pressing the "1" button while connecting.
This was tested on Fedora 17 with stock kernel 3.6.6-1.fc17.
Jack was set to 512 Frames/period and 3 periods/buffer, and in a
24h
recording I got no xruns.
I did not manage to choose a sample rate unlike 48000, though.
With lsusb, I can see 2 configurations for the same device, and
the
second one has bInterfaceProtocol = 32 for all interfaces except
http://pastebin.com/zwq0VVbM

Hi Hans,
Thank you for provided information.
So, some usbPre2 have bNumConfigurations=2 when "1" is not pressed
but not all usbPre2 (mine or alexander devices have only one
"Configuration Descriptor"). Your device descriptor contains a
UAC2 configuration descriptor, This sound good.
Perhaps there is different firmware ?
I have the 1.03 firmware. Can you provide your firmware level ?

Hmmm, same firmware 1.03 version here.
Which kernel are you running?

Post by s***@free.fr
Can you test 192khz value in jackd ?

No luck with this either - fastest one I get is 48000. This
corresponds
to the output of lsusb, which does not list samplerates over 48000
for
this device.

I have tried different kernel, 3.2 to 3.7.1, vanilla or ubuntu kernel.

The lsusb does not means that you are limited to 48000.

The lsusb provides the "devices descriptor" and a devices descriptors has one or more "configuration descriptor". The kernel chooses one of the "configuration descriptor".
In your device descriptor (provided directly by the device) there is two possibles configuration descriptons (the bNumConfigurations=2). The first one corresponds to the UAC1 mode in high-speed (this is my one configuration) and so limited to 48000. The second one is the UAC2 mode (the expected mode).

Perhaps the kernel choose the fist good one, so UAC1 .

Can you send the result of cat /proc/asound/USBPre2/stream0 ?

Olivier

Hans Wilmers

2013-01-10 22:23:56 UTC

Post by s***@free.fr

Post by Hans Wilmers
No luck with this either - fastest one I get is 48000. This
corresponds
to the output of lsusb, which does not list samplerates over 48000
for
this device.

I have tried different kernel, 3.2 to 3.7.1, vanilla or ubuntu kernel.
The lsusb does not means that you are limited to 48000.
The lsusb provides the "devices descriptor" and a devices descriptors has one or more "configuration descriptor". The kernel chooses one of the "configuration descriptor".
In your device descriptor (provided directly by the device) there is two possibles configuration descriptons (the bNumConfigurations=2). The first one corresponds to the UAC1 mode in high-speed (this is my one configuration) and so limited to 48000. The second one is the UAC2 mode (the expected mode).
Perhaps the kernel choose the fist good one, so UAC1 .
Can you send the result of cat /proc/asound/USBPre2/stream0 ?

Yes, see below.

/ Hans

--------------- /proc/asound/USBPre2/stream0 -------------

Sound Devices USBPre2 at usb-0000:00:1a.0-1.2, high speed : USB Audio

Playback:
Status: Stop
Interface 1
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 6 OUT (ASYNC)
Rates: 8000, 16000, 24000, 32000, 44100, 48000
Data packet interval: 1000 us
Interface 1
Altset 2
Format: S24_3LE
Channels: 2
Endpoint: 6 OUT (ASYNC)
Rates: 8000, 16000, 24000, 32000, 44100, 48000
Data packet interval: 1000 us

Capture:
Status: Stop
Interface 2
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 5 IN (ASYNC)
Rates: 8000, 16000, 24000, 32000, 44100, 48000
Data packet interval: 1000 us
Interface 2
Altset 2
Format: S24_3LE
Channels: 2
Endpoint: 5 IN (ASYNC)
Rates: 8000, 16000, 24000, 32000, 44100, 48000
Data packet interval: 1000 us

--------------------------------------------------------------

Hans Wilmers

2013-01-11 15:26:42 UTC

I have access to a PreSonus Audiobox 1818VSL today, and it gets
instantly recognised with 18+18 channels. I tested the analog inputs and
outputs, and these work fine with up to 24/96.

With lsusb, two configurations are shown, and both have
bInterfaceProtocol = 32.

Output of dmesg and lsusb here:
http://pastebin.com/V3P7zi93

/ Hans

Robin Gareus

2013-01-11 15:32:37 UTC

I have access to a PreSonus Audiobox 1818VSL today, and it gets
instantly recognised with 18+18 channels. I tested the analog inputs and
outputs, and these work fine with up to 24/96.

It is known to work well under GNU/Linux:

http://wiki.linuxaudio.org/wiki/current_audio_gear#presonus_-_1818vsl_usb2

Louis Gorenfeld

2013-01-11 22:17:38 UTC

Hi,
There are some glitches in the current ALSA (1.0.25) implementation
of UAC2, at least when used with the 1818VSL. It does mostly work (in
UAC2 mode, too). What I have noticed, aside from the click, is this:

- The sample clock selector doesn't work by default. I made a patch
that addresses this:
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-January/058141.html

- The mixer control names are all prefixed with "AudioBox 1818 VSL
Clock Selector" (which is the name of the first control)

- Note that there are two mutes in the mixer-- one per-channel and one
master mute. The same is true of input muting. If you're not hearing
anything, check this first.

- Don't turn it off when an audio stream is processing or it'll risk a
kernel panic. Or, at least, that has been my experience.

- There appears to be a general compatibility issue with i7 and the
PreSonus (cross-platform; it'll happen on Windows too). I believe this
is a known bug that is being addressed. This manifests as a subtle
click once a minute or so, from the machine I tried it on.

Lemme know how it works out for you!

-Louis

I have access to a PreSonus Audiobox 1818VSL today, and it gets
instantly recognised with 18+18 channels. I tested the analog inputs and
outputs, and these work fine with up to 24/96.

http://wiki.linuxaudio.org/wiki/current_audio_gear#presonus_-_1818vsl_usb2
_______________________________________________
Linux-audio-user mailing list
http://lists.linuxaudio.org/listinfo/linux-audio-user

Robin Gareus

2013-01-15 20:33:55 UTC

Post by Louis Gorenfeld
- The sample clock selector doesn't work by default. I made a patch
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-January/058141.html

confirmed working here with
linux 3.2.35-2 SMP PREEMPT RT 3.2.35-2 i686 pae

and 'amixer' as well as 'alsamixer'

thanks,
robin

Louis Gorenfeld

2013-01-15 22:43:58 UTC

Hmm did it work before my patch? That'd be interesting if it's down to
a firmware version difference or something like that.

Post by Louis Gorenfeld
- The sample clock selector doesn't work by default. I made a patch
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-January/058141.html

confirmed working here with
linux 3.2.35-2 SMP PREEMPT RT 3.2.35-2 i686 pae
and 'amixer' as well as 'alsamixer'
thanks,
robin

drew Roberts

2013-01-26 16:13:39 UTC

I have access to a PreSonus Audiobox 1818VSL today, and it gets
instantly recognised with 18+18 channels. I tested the analog inputs and
outputs, and these work fine with up to 24/96.

http://wiki.linuxaudio.org/wiki/current_audio_gear#presonus_-_1818vsl_usb2

Anyone recorded multiple tracks at once into ardour using this interface?

all the best,

drew

Robin Gareus

2013-01-26 22:40:46 UTC

On 01/26/2013 05:13 PM, drew Roberts wrote:
[..]

Post by Hans Wilmers
I have access to a PreSonus Audiobox 1818VSL today, and it gets
instantly recognised with 18+18 channels. I tested the analog inputs and
outputs, and these work fine with up to 24/96.

http://wiki.linuxaudio.org/wiki/current_audio_gear#presonus_-_1818vsl_usb2

Anyone recorded multiple tracks at once into ardour using this interface?

Certainly. All 8 analog inputs at once without any issues. - Ardour3 in
this case, but Ardour does not care: Since jackd (actually ALSA) works
reliably, all is good. You get a constant stream of 18 ins and 18 outs.

I have not yet had any need for recording mixed analog+digital sessions
but I've done some S/Pdif capturing and tested ADAT.

ciao,
robin

drew Roberts

2013-01-27 02:09:42 UTC

Post by Robin Gareus
[..]

Post by Hans Wilmers
I have access to a PreSonus Audiobox 1818VSL today, and it gets
instantly recognised with 18+18 channels. I tested the analog inputs
and outputs, and these work fine with up to 24/96.

http://wiki.linuxaudio.org/wiki/current_audio_gear#presonus_-_1818vsl_us
b2

Anyone recorded multiple tracks at once into ardour using this interface?

Thanks so much.

Post by Robin Gareus
I have not yet had any need for recording mixed analog+digital sessions
but I've done some S/Pdif capturing and tested ADAT.

What sort of latency can you get down to?

Post by Robin Gareus
ciao,
robin

drew

Kees van Veen

2013-01-29 20:47:58 UTC

Post by Robin Gareus
I have not yet had any need for recording mixed analog+digital sessions
but I've done some S/Pdif capturing and tested ADAT.

What sort of latency can you get down to?

Hi,

I've only used the 8 analog inputs together with Mixbus on ubuntu 12.04
lowlatency kernel. I could get to 128/3 (48k) in qjackctl and one time
64/3 without xruns, but I think that was the ppa rt kernel, can't
remember. I've only used the Presonus with all 8 inputs active once,
normally I have 2 to 4 active.

Cheers,
Kees

Len Ovens

2013-01-29 21:15:43 UTC

Post by Kees van Veen

Post by Robin Gareus
I have not yet had any need for recording mixed analog+digital sessions
but I've done some S/Pdif capturing and tested ADAT.

What sort of latency can you get down to?

Hi,
I've only used the 8 analog inputs together with Mixbus on ubuntu 12.04
lowlatency kernel. I could get to 128/3 (48k) in qjackctl and one time
64/3 without xruns, but I think that was the ppa rt kernel, can't
remember. I've only used the Presonus with all 8 inputs active once,
normally I have 2 to 4 active.

How do you keep inputs (or outputs) from being active? It seems to me,
that if you can see the input in jack, that jack is streaming audio from
it even if it is all zeros (or at least servicing the port at the same
interval as any other port). So if you can see the adat and s/pdif inputs
all the time, then jack is working just as hard as if you have 18 active
inputs.

--
Len Ovens
www.OvenWerks.net

Joel Roth

2013-01-30 03:44:08 UTC

Post by Len Ovens
How do you keep inputs (or outputs) from being active? It seems to me,
that if you can see the input in jack, that jack is streaming audio from
it even if it is all zeros (or at least servicing the port at the same
interval as any other port). So if you can see the adat and s/pdif inputs
all the time, then jack is working just as hard as if you have 18 active
inputs.

Greetings,

AFAIK, JACK doesn't take much CPU to service
its graph nodes.

You could probably have hundreds of them
and JACK wouldn't break a sweat.

--
Joel Roth

Kees van Veen

2013-01-30 07:10:36 UTC

-------- Original Message --------
Subject: Re: [LAU] USB2 Audio, PreSonus Audiobox 1818VSL -- was: Sound
Devices USBPre2, UAC2 status
From: Len Ovens <***@ovenwerks.net>
To: Kees van Veen <***@gmail.com>
CC: "LAU" <linux-audio-***@lists.linuxaudio.org>
Date: Tue Jan 29 2013 22:15:43 GMT+0100 (CET)

Post by Len Ovens

Post by Kees van Veen
I've only used the 8 analog inputs together with Mixbus on ubuntu 12.04

Post by Kees van Veen
lowlatency kernel. I could get to 128/3 (48k) in qjackctl and one time
64/3 without xruns, but I think that was the ppa rt kernel, can't
remember. I've only used the Presonus with all 8 inputs active once,
normally I have 2 to 4 active.

Sorry, I meant indeed connected or plugged instead of 'active'.

Robin Gareus

2013-01-30 18:14:11 UTC

Post by drew Roberts
What sort of latency can you get down to?

Hi Drew,

On linux 3.2.0-4-rt-686-pae (debian) with ondemand governor and old
gnome2 on a Thinkpad X60s. jackdmp 1.9.10 (recent git)

This works reliably; no x-runs:
jackd -d alsa -d hw:2 -r 48000 -p 64 -n 3
jack-delay measures: 403.949 frames 8.416 ms

Occasional rare x-runs with
jackd --sync -d alsa -d hw:2 -r 48000 -p 64 -n 2
roundtrip latency: 274.945 frames 5.728 ms

Now we're closing in...
jackd --sync -d alsa -d hw:2 -r 48000 -p 32 -n 2
roundtrip latency: 175.953 frames 3.666 ms
x-runs depend on system load. jack_capture still runs x-runs free for >
1 hour. Idle DSP load is only 5.6% with the CPU in low-power (1GHz). Yet
jack_delay alone bumps DSP load up to 20%.

At 96kHZ the minimum period is 64 fpp. The lowest setting is not what I
would take on stage but it works. jack_delay alone is causing 35% DSP
load. ondemand gov switches between 1GHz and 1.67 GHz, no x-runs in the
last 2 mins, but they'll come..
jackd --sync -d alsa -d hw:2 -r 96000 -p 64 -n 2
roundtrip latency: 276.273 frames 2.878 ms

best,
robin

Fons Adriaensen

2013-01-30 22:44:07 UTC

Post by Robin Gareus
jackd -d alsa -d hw:2 -r 48000 -p 64 -n 3
jack-delay measures: 403.949 frames 8.416 ms
Occasional rare x-runs with
jackd --sync -d alsa -d hw:2 -r 48000 -p 64 -n 2
roundtrip latency: 274.945 frames 5.728 ms

That's odd. The difference should be one period, 64 frames.
But it is 129 frames.

Post by Robin Gareus
Now we're closing in...
jackd --sync -d alsa -d hw:2 -r 48000 -p 32 -n 2
roundtrip latency: 175.953 frames 3.666 ms
x-runs depend on system load. jack_capture still runs x-runs free for >
1 hour. Idle DSP load is only 5.6% with the CPU in low-power (1GHz). Yet
jack_delay alone bumps DSP load up to 20%.

The % load for jack_delay shouldn't depend much on the period size,
it just processes period_size frames each time.

If it does there could be significant wakeup jitter - jack measures
the worst case load IIRC.

Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

Robin Gareus

2013-01-31 02:22:30 UTC

This works reliably; no x-runs: jackd -d alsa -d hw:2 -r 48000 -p
64 -n 3 jack-delay measures: 403.949 frames 8.416 ms
Occasional rare x-runs with jackd --sync -d alsa -d hw:2 -r 48000
-p 64 -n 2 roundtrip latency: 274.945 frames 5.728 ms

That's odd. The difference should be one period, 64 frames. But it
is 129 frames.

Note the --sync in the 2nd command. Hence the nominal difference is
2*64 frames. "--sync [..identical..] -n 2" vs "[..identical..] -n 3"

ciao,
robin

Giso Grimm

2014-12-09 08:35:03 UTC

Post by s***@free.fr
Some old posts exist about the UAC2 support for the Sound Devices
USBPre2 but some problem remains.
The current status is that this sound card is supported as a USB 1.1
card in high-speed mode.
But this card is not seen as a Usb Audio Class 2 on Linux. On Mac OS
X this card is recognized as UAC2.

I have access to a PreSonus Audiobox 1818VSL today, and it gets
instantly recognised with 18+18 channels. I tested the analog inputs and
outputs, and these work fine with up to 24/96.

Does anyone know about the state of the other Presonus audiobox sound
cards (44VSL, 22VSL)?

- Giso

Post by Hans Wilmers
With lsusb, two configurations are shown, and both have
bInterfaceProtocol = 32.
http://pastebin.com/V3P7zi93
/ Hans
_______________________________________________
Linux-audio-user mailing list
http://lists.linuxaudio.org/listinfo/linux-audio-user

s***@free.fr

2013-01-11 15:42:42 UTC

----- Mail original -----

Envoyé: Jeudi 10 Janvier 2013 23:23:56
Objet: Re: [LAU] Sound Devices USBPre2, UAC2 status

Post by s***@free.fr

Post by Hans Wilmers
No luck with this either - fastest one I get is 48000. This
corresponds
to the output of lsusb, which does not list samplerates over 48000
for
this device.

I have tried different kernel, 3.2 to 3.7.1, vanilla or ubuntu
kernel.
The lsusb does not means that you are limited to 48000.
The lsusb provides the "devices descriptor" and a devices
descriptors has one or more "configuration descriptor". The kernel
chooses one of the "configuration descriptor".
In your device descriptor (provided directly by the device) there
is two possibles configuration descriptons (the
bNumConfigurations=2). The first one corresponds to the UAC1 mode
in high-speed (this is my one configuration) and so limited to
48000. The second one is the UAC2 mode (the expected mode).
Perhaps the kernel choose the fist good one, so UAC1 .
Can you send the result of cat /proc/asound/USBPre2/stream0 ?

Yes, see below.
/ Hans
--------------- /proc/asound/USBPre2/stream0 -------------
Sound Devices USBPre2 at usb-0000:00:1a.0-1.2, high speed : USB Audio
Status: Stop
Interface 1
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 6 OUT (ASYNC)
Rates: 8000, 16000, 24000, 32000, 44100, 48000
Data packet interval: 1000 us
Interface 1
Altset 2
Format: S24_3LE
Channels: 2
Endpoint: 6 OUT (ASYNC)
Rates: 8000, 16000, 24000, 32000, 44100, 48000
Data packet interval: 1000 us

Hi Hans,

So , effectively you are limited to 48000.
I supposed that the linux kernel chooses this first valid configuration descriptor.

This behavior can be modified in the kernel with adding a quirk in the code.
If my usbPre2 has the good device descripton, I can devlop and test this patch.
But my devices does not offer the UAC2 configuration descriptor.

I have write a post on the Sound Devices Forum. Perhaps I will have help to understand why my device has this strange behavior and correct it.

In this case, I think I can patch the kernel to have the UAC2 mode...

Olivier

alexander

2013-01-14 21:19:36 UTC

Post by s***@free.fr
----- Mail original -----

Envoyé: Jeudi 10 Janvier 2013 23:23:56
Objet: Re: [LAU] Sound Devices USBPre2, UAC2 status

Post by s***@free.fr

Post by Hans Wilmers
No luck with this either - fastest one I get is 48000. This
corresponds
to the output of lsusb, which does not list samplerates over 48000
for
this device.

I have tried different kernel, 3.2 to 3.7.1, vanilla or ubuntu
kernel.
The lsusb does not means that you are limited to 48000.
The lsusb provides the "devices descriptor" and a devices
descriptors has one or more "configuration descriptor". The kernel
chooses one of the "configuration descriptor".
In your device descriptor (provided directly by the device) there
is two possibles configuration descriptons (the
bNumConfigurations=2). The first one corresponds to the UAC1 mode
in high-speed (this is my one configuration) and so limited to
48000. The second one is the UAC2 mode (the expected mode).
Perhaps the kernel choose the fist good one, so UAC1 .
Can you send the result of cat /proc/asound/USBPre2/stream0 ?

Hi Hans,
So , effectively you are limited to 48000.
I supposed that the linux kernel chooses this first valid configuration descriptor.
This behavior can be modified in the kernel with adding a quirk in the code.
If my usbPre2 has the good device descripton, I can devlop and test this patch.
But my devices does not offer the UAC2 configuration descriptor.
I have write a post on the Sound Devices Forum. Perhaps I will have help to understand why my device has this strange behavior and correct it.
In this case, I think I can patch the kernel to have the UAC2 mode...
Olivier
_______________________________________________
Linux-audio-user mailing list
http://lists.linuxaudio.org/listinfo/linux-audio-user

that would be amazing! I just joined the forum to raise their awereness
but I can't post yet it seems!

I submitted a bugreport to alsa's bugtracker aloong time ago where there
have been some additional discussion and someone actually have written
somekind of patch, I never got it to work tho.. but the tracker is down
now it seems.... I also started some threads on the alsa mailing list,
both users and dev.

alexander

2013-01-21 14:58:55 UTC

Ok, I reconnected without pressing "1".
Bus 002 Device 002: ID 0926:0202
bNumConfigurations 2

Strange, I have never 2 on bNumConfigurations ! Somebody can test it on its card ?
This is perhaps my problem, my card only provides one "Configuration Descriptor".
The second one is certainly the UAC2 "Configuration Descriptor".
The lsusb without 1 pressed : http://pastebin.com/8yjjASv7
The lsusb with 1 pressed : http://pastebin.com/pGFdjR4K
The usbmon trace of the insertion of the usbpre2 (without "1") : http://pastebin.com/pySC4Age
This sound card is great, it is very disappointing to not be able to used it with all functionnalities.
I search help in order to debug this problem.
I am devlopper, I can test kernel patches without problem.
Thank for any idea (or patch).
Olivier
_______________________________________________
Linux-audio-user mailing list
http://lists.linuxaudio.org/listinfo/linux-audio-user

Oliver check your SD thread
http://forum.sounddevices.com/showthread.php?3785-Linux-status-for-usbPre2&highlight=linux
Paul Isaacs of Sound Devices has posted a potentially helpful reply!

s***@free.fr

2013-01-24 21:40:25 UTC

----- Mail original -----

Envoyé: Lundi 21 Janvier 2013 15:58:55
Objet: Re: [LAU] Sound Devices USBPre2, UAC2 status
Oliver check your SD thread
http://forum.sounddevices.com/showthread.php?3785-Linux-status-for-usbPre2&highlight=linux
Paul Isaacs of Sound Devices has posted a potentially helpful reply!

Hi,

I have some succes on UAC2 support for the USBPRe2.

Like indicated by Paul form Sound Devices, the sound card recognize that the OS is a Windows and so only have one configuration descriptor in the device desciptor : the UAC1 descriptor. The used method is on the STANDARD_REQUEST_GET_DESCRIPTOR if the wLength is 64 the OS is supposed to be Windows.

But Linux have taken the same behavior like of Windows and take also the 64 value.
In driver/usb/core/hub.c : #define GET_DESCRIPTOR_BUFSIZE 64

If you put another value (like 65) the device descriptor have now 2 configuration descriptor (UAC1 and UAC2).
It seems mandatory to have a unplug/plug of the sound card (the first "get_descriptor" seems to determine the sound card behavior).

My "lsusb -v -d 0926:" : http://pastebin.com/nFTN2E04

First step is OK.
Nevertheless, the sound card remains in UAC1.
The kernel choose the first valid configuration descriptor and the UAC1 is OK so....

I have test a ugly patch.
At the end of the function usb_choose_configuration() (in file driver/usb/core/generic.c) , I changed the behavior like this:
if(udev->product != NULL)
if(strlen(udev->product) >= 7)
if(strncmp(udev->product,"USBPre2",7) == 0)
{
i++;
printk("USBPre2: overwrite the choosen configuration to the follower :%d\n",i);
}
return i;

And that all, now the USBPRe2 is view as a UAC2 sound card.

I have played a 24bit/192khz music.
This is the status of the sound card:

$ cat /proc/asound/USBPre2/stream0
Sound Devices USBPre2 at usb-0000:00:1d.0-1.3, high speed : USB Audio

Playback:
Status: Running
Interface = 1
Altset = 2
Packet Size = 156
Momentary freq = 192000 Hz (0x18.0000)
Feedback Format = 8.16
Packet Size = 0
Momentary freq = 192000 Hz (0x18.0000)
Interface 1
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 6 OUT (ASYNC)
Rates: 8000, 16000, 24000, 32000, 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
Interface 1
Altset 2
Format: S24_3LE
Channels: 2
Endpoint: 6 OUT (ASYNC)
Rates: 8000, 16000, 24000, 32000, 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us

Jackd is OK with "/usr/bin/jackd -P10 -p128 -dalsa -dhw:0 -r192000 -p2048 -n3 -m -H -M -P"

It's remains a problem : I am not able to performs a capture....

So, I hope that this information will permit to find a way to have a easy and complete UAC2 support for this sound card.

Bye
Olivier

alexander

2013-01-25 22:35:29 UTC