On Thu, Jan 30, 2014 at 12:05 AM, Clemens Ladisch <clemens(a)ladisch.de>wrote:
> Romain Michon wrote:
> > I'm trying to use two audio interfaces (Guitar Link UC6102) in
> > parallel in Alsa on a UDOO board that runs Ubuntu. The two interfaces
> > are connected on the two USB 2.0 port available on the board: I'm not
> > using any hub. In 20% of the cases, this works fine and I'm able to
> > use the two interface as one single "virtual" interface with 4 inputs
> > and 4 outputs (see my .asoundrc file bellow).
>
> So the hardware actually supports the required bandwidth.
>
Yep...
>
> > However, in 80% of the cases, this doesn't work and dmesg says:
> > "cannot submit datapipe for urb 0, error -28: not enough bandwidth".
>
> Sounds like a bug in the USB controller driver of your board.
>
You're right. I'll send an e-mail to the UDOO community, may be someone
had a similar issue... I'll keep you posted.
Thanks.
Romain
Hi Everyone,
I'm trying to use two audio interfaces (Guitar Link UC6102) in parallel in
Alsa on a UDOO board that runs Ubuntu. The two interfaces are connected on
the two USB 2.0 port available on the board: I'm not using any hub. In 20%
of the cases, this works fine and I'm able to use the two interface as one
single "virtual" interface with 4 inputs and 4 outputs (see my .asoundrc
file bellow). However, in 80% of the cases, this doesn't work and dmesg
says: "cannot submit datapipe for urb 0, error -28: not enough bandwidth".
Any idea of where this problem comes from? I can use 4 of these interfaces
on the same USB port with a hub on my laptop without any problem...
Thanks for your help :)
Cheers,
Romain
.asoundrc:
pcm.myMAIN {
type route;
slave.pcm {
type multi;
slaves.a.pcm "myOUT0";
slaves.b.pcm "myOUT1";
slaves.a.channels 2;
slaves.b.channels 2;
bindings.0.slave a;
bindings.0.channel 0;
bindings.1.slave a;
bindings.1.channel 1;
bindings.2.slave b;
bindings.2.channel 0;
bindings.3.slave b;
bindings.3.channel 1;
}
ttable.0.0 1;
ttable.1.1 1;
ttable.2.2 1;
ttable.3.3 1;
#ttable.0.2 1; # front left
#ttable.1.3 1; # front right
#ttable.0.4 1; # copy front left to rear left
#ttable.1.5 1; # copy front right to rear right
}
ctl.myMAIN {
type hw;
card CODEC;
}
pcm.builtIn {
type hw
card vt1613audio
}
ctl.builtIn {
type hw
card vt1613audio
}
pcm.myOUT0 {
type hw
card CODEC
}
ctl.myOUT0 {
type hw
card CODEC
}
pcm.myOUT1 {
type hw
card CODEC_1
}
ctl.myOUT1 {
type hw
card CODEC_1
}
--
Romain Michon
PhD Candidate
Center for Computer Research in Music and Acoustics
Stanford Universityhttp://ccrma.stanford.edu/~rmichon
Before "modern" computers as the Atari ST were able to sync to tape by
SMPTE, computers as the Commodore 64 synced by some kind of click,
without a time code. IOW you couldn't cue at a wanted position, you
always needed to start from the beginning. This sync was not less good
than sync between MIDI and audio is nowadays, in my experiences it was
much more accurate, than the supposedly "frame accuracy" between MIDI
and audio of Linux DAWs is nowadays.
YMMV!
Regards,
Ralf
Dear list,
did anyone have success using jackd with the RME HDSP card and
settings
jackd -dalsa -r44100 -p32 -n2 -D -Chw:DSP -Phw:DSP -i18 -o18
?
Here is the post from the messages window:
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben
Hohn and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
15:31:07.074 JACK was started with PID=24668.
loading driver ..
apparent rate = 44100
creating alsa driver ...
hw:DSP|hw:DSP|32|2|44100|18|18|nomon|swmeter|-|32bit
configuring for 44100Hz, period = 32 frames (0.7 ms), buffer = 2
periods
ALSA: final selected sample format for capture: 32bit integer
little-endian
ALSA: cannot set period size to 32 frames for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
15:31:07.095 JACK was stopped successfully.
15:31:09.097 Could not connect to JACK server as client. - Overall
operation failed. - Unable to connect to server. Please check the
messages window for more info.
Thanks for sharing your experiences.
best, P
[Sorry for cross-posting, please distribute]
We are happy to announce the next issue of the Linux Audio Conference
(LAC), May 1-4, 2014 @ ZKM | Institute for Music and Acoustics, in
Karlsruhe, Germnany.
http://lac.linuxaudio.org/2014/
The Linux Audio Conference is an international conference that brings
together musicians, sound artists, software developers and researchers,
working with Linux as an open, stable, professional platform for audio
and media research and music production. LAC includes paper sessions,
workshops, and a diverse program of electronic music.
*Call for Papers, Workshops, Music and Installations*
We invite submissions of papers addressing all areas of audio processing
and media creation based on Linux. Papers can focus on technical,
artistic and scientific issues and should target developers or users. In
our call for music, we are looking for works that have been produced or
composed entirely/mostly using Linux.
The online submission of papers, workshops, music and installations is
now open at http://lac.linuxaudio.org/2014/participation
The Deadline for all submissions is January 27th, 2014 (23:59 HAST).
You are invited to register for participation on our conference website.
There you will find up-to-date instructions, as well as important
information about dates, travel, lodging, and so on.
This year's conference is hosted by the ZKM | Institute for Music und
Acoustics (IMA). The IMA is a forum for international discourse and
exchange and combines artistic work with research and development in the
context of electroacoustic music. By holding concerts, symposia and
festivals on a regular basis it brings together composers, musicians,
musicologists, music software developers and listeners interested in
contemporary music. Artists in Residence and software developers work on
their productions in studios at the institute. With digital sound
synthesis, algorithmic composition, live-electronics up to radio plays,
interactive sound installations and audiovisual productions their
creations cover a broad range of what digital technology can inspire the
musical fantasy to.
The ZKM is proud to be the place of the LAC for the fifth time after
having initiated the conference in 2003.
http://www.zkm.de/musik
We look forward to seeing you in Karlsruhe in May!
Sincerely,
The LAC 2014 Organizing Team
sorry for >< please >> <<
Hi all,
The Linux Audio Conference submissions deadline has been extended! It is
now February 3rd, 2014 (23:59 HAST)
So, if you were considering to submit a paper but couldn't make up your
mind yet, here is your chance to become active! Never forget that this
conference lives through the people participating in it.
February 3rd is the new deadline for all submission types: papers,
music, installations, workshop proposals.
Check out the link below for more info:
http://lac.linuxaudio.org/2014/participation
Please spread this information to anyone who might be interested.
If you have any questions, drop us a line at lac(a)linuxaudio.org
We are looking forward to seeing you in Karlsruhe in May!
Thanks,
The LAC2014 organization team
Hi,
there are 2 things I don't understand.
1. Linux-Rt and TSC
===================
All Rt kernels for all Linux distros I use seem to have an issue
regarding to TSC.
I wonder what to do, to get rid of those messages, IOW how to fix the
issue.
E.g. Debian 32-bit architecture
root@debi386:/mnt/arch/home/rocketmouse/Desktop# dmesg | grep TSC
[ 0.000000] Fast TSC calibration using PIT
[ 0.000000] Marking TSC unstable due to TSCs unsynchronized
root@debi386:/mnt/arch/home/rocketmouse/Desktop# grep TSC /var/log/messages
Jan 16 09:28:08 debi386 kernel: [ 0.000000] tsc: Fast TSC calibration using PIT
Jan 16 09:28:08 debi386 kernel: [ 0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
Jan 16 09:28:08 debi386 kernel: [ 0.003000] calibrate_delay_direct() ignoring timer_rate as we
had a TSC wrap around start=4287833042 >=post_end=13864416
Jan 16 09:50:58 debi386 kernel: [ 0.000000] tsc: Fast TSC calibration using PIT
Jan 16 09:50:58 debi386 kernel: [ 0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
Jan 22 12:05:33 debi386 kernel: [ 0.000000] Fast TSC calibration using PIT
Jan 22 12:05:33 debi386 kernel: [ 0.000000] Marking TSC unstable due to TSCs unsynchronized
Jan 22 are messages when booted to kernel 3.2.0-4-rt-686-pae i686 from
the repositories.
Jan 16 might be a broken kernel 3.8.13-rt14-pae-rocketmouse I build
based on a 3.8.13-rt14 x86_64 config.
E.g. Arch Linux 64-bit architecture
On startup I see "x86 Rt requires FEATURE_CONSTANT_TSC" or similar for
Arch Linux Rt kernels from the repositories and for the once I build.
This link for Chromebooks was the best explanation I found:
http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/tsc-resynch…
root@debi386:/mnt/arch/home/rocketmouse/Desktop# grep tsc /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht
syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow
extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic
cr8_legacy 3dnowprefetch lbrv
flags : [snip] tsc [snip]
2. Linux-Rt and IRQ allocation
==============================
All kernels I used in the last years for *buntu, Debian and Arch Linux
<= 3.8.13-rt14 (kernels > 3.8.13-rt14 don't work on my machine) give my
graphics it's own IRQ, the Debian kernel 3.2.0-4-rt-686-pae doesn't.
What options do I need to enable, so that it will allocate the graphics
it's own IRQ too, instead of sharing it with the RME card?
Regards,
Ralf
Hello all,
AFAIK the Focusrite Scarlett 18i8 USB interface works on Linux.
* Can anyone confirm this ?
* Should it work with a Raspberry Pi ?
TIA,
--
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)
