18 Jan
2005
18 Jan
'05
7:40 p.m.
I posted this to alsa-devel but since my previous post on this list
generated a lot of interest, I am just reposting it here.
As promised, here's an updated patch to add real multichannel playback
support (and improved multichannel capture) to the emu10k1 driver.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v001.patch
Please test it and report any problems. I am especially interested in
any regressions that impact regular PCM playback (the hw:0,0 device).
QuickStart:
$ jackd -R -v -d alsa -P hw:0,3 -C hw:0,2 -S
I tested this and it works well with 16in/16out at 128, 256, 512 frames.
32 and 64 should work too but I can't test as I'm running a stock 2.6.10
kernel for now ;-). You can check that the routing is correct by
connecting a JACK client to the playback ports corresponding to the FX
buses described in Documentation/Audigy-mixer.txt and
Documentation/SB-Live-mixer.txt, and verifying that the output appears
on that channel (the FX buses are numbered from 0 but JACK numbers
clients from 1). For example (from SB-Live-mixer.txt):
name='Music Playback Volume',index=0
This control is used to attenuate samples for left and right MIDI FX-bus
accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
So "alsaplayer -o jack -d alsa_pcm:playback_5,alsa_pcm:playback_6"
should output to FX buses 4 and 5, which you can test by lowering the
'Music' control in alsamixer. With an SBLive, use ports 1 and 2 for the
front channels, 3 and 4 for the rear channels. The Audigy uses
different channels, see the above docs for more info.
In addition to multichannel recording applications, this should also be
useful for OpenAL implementations, which are currently restricted to
using 21 sources due to the use of an extra voice per stereo PCM. This
should allow up to 63 sources.
This also adds some new register info including a per channel half loop
interrupt that I have discovered by reverse engineering the Windows
drivers.
Improvements over previous versions:
- Routes the 16 channels to the 16 FX buses by default.
- Enables the first 16 FX capture outputs by default, required for
full duplex operation at latencies lower than 512 frames.
- Rewrote the voice allocator to use a more efficient round
robin algorithm, eliminating the need to reserve the
first 16 voices for the multichannel device. The next free voice
is maintained in the card record and the search starts from there.
- Use an extra voice for playback timing rather than the EFX capture
interrupt. I was only ever able to get that to work at 64 frames. Also
there are definite advantages to being able to use the capture and
playback devices independently.
- Use the newly discovered per-channel half loop interrupt source for
the extra voice rather than the channel loop interrupts. For unknown
reasons, this works better for multichannel playback, and does not seem
to affect regular PCM playback at all.
TODO:
- Fix the send routing and volume controls for the multichannel device.
The current (copy and paste) solution assumes either one or two voices
per PCM. So the default settings work fine but changing them with the
mixer is likely to have unpredictable effects.
- EFX capture should capture output channels 16-32 (mostly unused now)
by default, so that we only capture the sources the user has connected
to the multichannel recording inputs in the DSP manager. Typically FX
buses 0-15 would be connected directly to FX outputs 16-32 so the
capture channels would correspond directly to the playback channels. In
order for this to work the default DSP configuration has to be changed
slightly.
Lee
18 Jan
18 Jan
8:36 p.m.
Lee Revell wrote:
I posted this to alsa-devel but since my previous post
on this list
generated a lot of interest, I am just reposting it here.
As promised, here's an updated patch to add real multichannel playback
support (and improved multichannel capture) to the emu10k1 driver.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v001.patch
Please test it and report any problems. I am especially interested in
any regressions that impact regular PCM playback (the hw:0,0 device).
QuickStart:
$ jackd -R -v -d alsa -P hw:0,3 -C hw:0,2 -S
I tested this and it works well with 16in/16out at 128, 256, 512 frames.
32 and 64 should work too but I can't test as I'm running a stock 2.6.10
kernel for now ;-). You can check that the routing is correct by
connecting a JACK client to the playback ports corresponding to the FX
buses described in Documentation/Audigy-mixer.txt and
Documentation/SB-Live-mixer.txt, and verifying that the output appears
on that channel (the FX buses are numbered from 0 but JACK numbers
clients from 1). For example (from SB-Live-mixer.txt):
name='Music Playback Volume',index=0
This control is used to attenuate samples for left and right MIDI FX-bus
accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
So "alsaplayer -o jack -d alsa_pcm:playback_5,alsa_pcm:playback_6"
should output to FX buses 4 and 5, which you can test by lowering the
'Music' control in alsamixer. With an SBLive, use ports 1 and 2 for the
front channels, 3 and 4 for the rear channels. The Audigy uses
different channels, see the above docs for more info.
In addition to multichannel recording applications, this should also be
useful for OpenAL implementations, which are currently restricted to
using 21 sources due to the use of an extra voice per stereo PCM. This
should allow up to 63 sources.
This also adds some new register info including a per channel half loop
interrupt that I have discovered by reverse engineering the Windows
drivers.
Improvements over previous versions:
- Routes the 16 channels to the 16 FX buses by default.
- Enables the first 16 FX capture outputs by default, required for
full duplex operation at latencies lower than 512 frames.
- Rewrote the voice allocator to use a more efficient round
robin algorithm, eliminating the need to reserve the
first 16 voices for the multichannel device. The next free voice
is maintained in the card record and the search starts from there.
- Use an extra voice for playback timing rather than the EFX capture
interrupt. I was only ever able to get that to work at 64 frames. Also
there are definite advantages to being able to use the capture and
playback devices independently.
- Use the newly discovered per-channel half loop interrupt source for
the extra voice rather than the channel loop interrupts. For unknown
reasons, this works better for multichannel playback, and does not seem
to affect regular PCM playback at all.
TODO:
- Fix the send routing and volume controls for the multichannel device.
The current (copy and paste) solution assumes either one or two voices
per PCM. So the default settings work fine but changing them with the
mixer is likely to have unpredictable effects.
- EFX capture should capture output channels 16-32 (mostly unused now)
by default, so that we only capture the sources the user has connected
to the multichannel recording inputs in the DSP manager. Typically FX
buses 0-15 would be connected directly to FX outputs 16-32 so the
capture channels would correspond directly to the playback channels. In
order for this to work the default DSP configuration has to be changed
slightly.
Lee
dear me, thanx a bunch - now for the stupid newbie question ... how in
heck do i apply this patch?
i'm using fedora core 2 ccrma setup (2.6.10 kernel, 1.0.8 alsa, jack
etc) but i'm guessing i'd have to forsake my apt-installed alsa and
compile it from source? that could get a bit messy, what with installed
dependencies etc ...
how should i go about this? i *so* bad want that kx-style multi-channel
support :)
shayne
8:51 p.m.
On Wed, 2005-01-19 at 11:55 +1100, Shayne O'Connor wrote:
dear me, thanx a bunch - now for the stupid newbie
question ... how in
heck do i apply this patch?
i'm using fedora core 2 ccrma setup (2.6.10 kernel, 1.0.8 alsa, jack
etc) but i'm guessing i'd have to forsake my apt-installed alsa and
compile it from source? that could get a bit messy, what with installed
dependencies etc ...
how should i go about this? i *so* bad want that kx-style multi-channel
support :)
Yes, for now the patch is against ALSA CVS. However it doesn't touch
alsa-lib, only the driver, so if you currently have ALSA installed as
modules you can get ALSA from CVS and only build in the alsa-driver
directory. I woukd not expect this to cause any dependency problems.
I will generate a patch against the 2.6.10 kernel source which should
make it easier.
Lee
19 Jan
19 Jan
12:22 p.m.
On Tue, 2005-01-18 at 18:40 -0500, Lee Revell wrote:
I posted this to alsa-devel but since my previous post
on this list
generated a lot of interest, I am just reposting it here.
As promised, here's an updated patch to add real multichannel playback
support (and improved multichannel capture) to the emu10k1 driver.
It was just pointed out to me that this patch disables the wavetable
synth. If you need this feature then please wait for the next version.
Lee
1:07 p.m.
On Wed, 2005-01-19 at 11:22 -0500, Lee Revell wrote:
On Tue, 2005-01-18 at 18:40 -0500, Lee Revell wrote:
OK, I have posted a new version which fixes this bug.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v002.patch
Lee
I posted this to alsa-devel but since my previous
post on this list
generated a lot of interest, I am just reposting it here.
As promised, here's an updated patch to add real multichannel playback
support (and improved multichannel capture) to the emu10k1 driver.
It was just pointed out to me that this patch disables the wavetable
synth. If you need this feature then please wait for the next version.
21 Jan
21 Jan
5:18 p.m.
On Wed, 2005-01-19 at 12:07 -0500, Lee Revell wrote:
On Wed, 2005-01-19 at 11:22 -0500, Lee Revell wrote:
Turns out the above patch did not really fix the problems with the
wavetable synth. I have a new patch which should really fix the
problem.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v003.patch
I tested multichannel PCM, regular PCM and MIDI playback all at the same
time and did not have any voice allocation failures.
Some people report that the patch makes their sound unusable, with
massive xrun storms, and also breaks regular PCM playback. Others
report it works fine.
Anyway, people who want to try this can check the above directory. I
won't be posting every new version here, check alsa-devel for updates.
Lee
On Tue, 2005-01-18 at 18:40 -0500, Lee Revell
wrote:
OK, I have posted a new version which fixes this bug.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v002.patch
I posted this to alsa-devel but since my previous
post on this list
generated a lot of interest, I am just reposting it here.
As promised, here's an updated patch to add real multichannel playback
support (and improved multichannel capture) to the emu10k1 driver.
It was just pointed out to me that this patch disables the wavetable
synth. If you need this feature then please wait for the next version.
20 Jan
20 Jan
1:39 a.m.
Lee Revell wrote:
QuickStart:
$ jackd -R -v -d alsa -P hw:0,3 -C hw:0,2 -S
here's what i get here:
[mrmachine@localhost mrmachine]$ jackd -v -d alsa -P hw:0,3 -C hw:0,2 -S
-i 2 -o 4
getting driver descriptor from /usr/lib/jack/jack_oss.so
getting driver descriptor from /usr/lib/jack/jack_alsa.so
getting driver descriptor from /usr/lib/jack/jack_dummy.so
jackd 0.99.36
Copyright 2001-2003 Paul Davis 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.
server `default' registered
loading driver ..
creating alsa driver ...
hw:0,3|hw:0,2|1024|2|48000|2|4|nomon|swmeter|-|16bit
ALSA: Cannot open PCM device alsa_pcm for playback. Falling back to
capture-only mode
control device hw:0
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
ALSA: cannot set channel count to 2 for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
registered builtin port type 32 bit float mono audio
required capabilities not available
capabilities: = cap_ipc_lock,cap_sys_nice,cap_sys_resource+e
new client: alsa_pcm, id = 1 type 1 @ 0x805e040 fd = -1
starting server engine shutdown
freeing shared port segments
stopping server thread
last xrun delay: 0.000 usecs
freeing engine shared memory
max usecs: 0.000, engine deleted
no message buffer overruns
cleaning up shared memory
cleaning up files
unregistering server `default'
[mrmachine@localhost mrmachine]$
i patched alsa 1.0.8 with your updated patch, and it compiled and
installed ok ... then i just rebooted the computer. thing is, i merely
installed it over the already existing planetccrma alsa-driver - would
that be ok, or should've i removed the existing one first?
in any case, the wavetable synth still doesn't seem to be working ... at
least, the tables are loaded with the default sf banks, but no sound is
output if i program a midi line in muse.
i'm not sure i get what's happening using hw:0,2 and hw:0,3 instead of
plain old hw:0 ?
anyway, this might all be a bit overwhelmingly confusing for me ...
without an interface like the kx-audio dsp manager, i'm a bit lost as to
routings etc ... (i've tried installing ld10k1, but the
init_soundblaster script fails to complete or load ... would the
capabilities your patch provides be accessible/routable through the
ld10k1 interface? that would indeed be good, and would encourage me to
get ld10k1 happening ...).
the *primary* capability i needed (seperation of the front and rear
channels for dj cueing) was solved while i was investigating how to
apply patches to source code and how to configure .asoundrc - all i
needed was this:
ctl.jack40 {
type hw
card 0
}
pcm.jack40 {
# "asym" allows for different handling of in/out devices
type asym
playback.pcm {
# route for mmap workaround
type route
slave.pcm surround40
ttable.0.0 1
ttable.1.1 1
ttable.2.2 1
ttable.3.3 1
}
capture.pcm {
# 2 channels only
type hw
card 0
}
}
now i can have headphone cueing in mixxx/djplay ... now to figure out
how to get gdam cued up (it doesn't use jack, so i guess it might be a
slightly different .asoundrc configuration).
basically, what i'm hoping to achieve is:
*ability to access a kx-audio-style dsp routing interface that can load
dsp filters/effects (like the noise-gate in kx dsp that, in windows, i
would put between the ac97 in-port and the mixer input to reduce noise
when recording guitar). i'm guessing that ld10k1 would provide this ...
*ability to simultaneously access and route multiple audio/effect/synth
channels. i'm guessing your multi-channel patch would provide most of
the capabilities here?
i must apologise for my lack of technical knowledge in helping you test
this patch - my audio work has, i guess, pretty humble requirements:
*record guitar/bass/vocals into either ardour or muse.
*use soundfonts (preferably loaded into soundcard memory)
*i have no midi keyboard, so all my midi stuff is either doodling with
vkeybd, more complex doodling with zynaddsubfx, or - when
composing/recording - programming into muse/rosegarden.
*independent front/rear channels.
as a result, i'm not too hip with some of the more advanced linux audio
options ...
i'll let you know if i progress any further.
shayne
2:28 p.m.
On Thu, 2005-01-20 at 17:00 +1100, Shayne O'Connor wrote:
Lee Revell wrote:
Lose the "-i 2 -o 4", and it will automatically open 16 capture and 16
playback channels (like the default kX ASIO config). Unfortunately,
opening fewer channels than 16 is not supported yet.
Also the wavetable problem is known and I am working on it. My goal is
basically the same as yours. Eventually the emu10k1 driver with ld10k1
will offer all the features the kX driver does.
Lee
QuickStart:
$ jackd -R -v -d alsa -P hw:0,3 -C hw:0,2 -S
here's what i get here:
[mrmachine@localhost mrmachine]$ jackd -v -d alsa -P hw:0,3 -C hw:0,2 -S
-i 2 -o 4
6:02 p.m.
Lee Revell wrote:
On Thu, 2005-01-20 at 17:00 +1100, Shayne O'Connor
wrote:
still no go -
[mrmachine@localhost mrmachine]$ jackd -v -d alsa -P hw:0,3 -C hw:0,2 -S
getting driver descriptor from /usr/lib/jack/jack_oss.so
getting driver descriptor from /usr/lib/jack/jack_alsa.so
getting driver descriptor from /usr/lib/jack/jack_dummy.so
jackd 0.99.36
Copyright 2001-2003 Paul Davis 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.
server `default' registered
loading driver ..
registered builtin port type 32 bit float mono audio
required capabilities not available
capabilities: = cap_ipc_lock,cap_sys_nice,cap_sys_resource+e
new client: alsa_pcm, id = 1 type 1 @ 0x8059a50 fd = -1
creating alsa driver ...
hw:0,3|hw:0,2|1024|2|48000|0|0|nomon|swmeter|-|16bit
ALSA: Cannot open PCM device alsa_pcm for playback. Falling back to
capture-only mode
control device hw:0
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
ALSA: cannot set period size to 1024 frames for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
starting server engine shutdown
freeing shared port segments
stopping server thread
last xrun delay: 0.000 usecs
freeing engine shared memory
max usecs: 0.000, engine deleted
no message buffer overruns
cleaning up shared memory
cleaning up files
unregistering server `default'
[mrmachine@localhost mrmachine]$
would my .asoundrc file be interfering? i have an sb live platinum, so
maybe the device i need is different?
Lee Revell wrote:
Lose the "-i 2 -o 4", and it will automatically open 16 capture and 16
playback channels (like the default kX ASIO config). Unfortunately,
opening fewer channels than 16 is not supported yet.
QuickStart:
$ jackd -R -v -d alsa -P hw:0,3 -C hw:0,2 -S
here's what i get here:
[mrmachine@localhost mrmachine]$ jackd -v -d alsa -P hw:0,3 -C hw:0,2 -S
-i 2 -o 4
Also the wavetable problem is known and I am working on
it. My goal is
basically the same as yours. Eventually the emu10k1 driver with ld10k1
will offer all the features the kX driver does.
is development of ld10k1 still happening?
shayne
6:16 p.m.
On Fri, 2005-01-21 at 09:25 +1100, Shayne O'Connor wrote:
till no go -
[mrmachine@localhost mrmachine]$ jackd -v -d alsa -P hw:0,3 -C hw:0,2 -S
getting driver descriptor from /usr/lib/jack/jack_oss.so
getting driver descriptor from /usr/lib/jack/jack_alsa.so
getting driver descriptor from /usr/lib/jack/jack_dummy.so
jackd 0.99.36
Copyright 2001-2003 Paul Davis 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.
server `default' registered
loading driver ..
registered builtin port type 32 bit float mono audio
required capabilities not available
capabilities: = cap_ipc_lock,cap_sys_nice,cap_sys_resource+e
new client: alsa_pcm, id = 1 type 1 @ 0x8059a50 fd = -1
creating alsa driver ...
hw:0,3|hw:0,2|1024|2|48000|0|0|nomon|swmeter|-|16bit
ALSA: Cannot open PCM device alsa_pcm for playback. Falling back to
capture-only mode
control device hw:0
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
ALSA: cannot set period size to 1024 frames for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
You're sure you have the correct ALSA modules loaded? Maybe you have
ALSA modules built into the kernel that are interfering. Or maybe you
need to run the snddevices.sh script.
What is in /proc/asound/devices?
Lee
6:56 p.m.
Lee Revell wrote:
You're sure you have the correct ALSA modules
loaded? Maybe you have
ALSA modules built into the kernel that are interfering. Or maybe you
need to run the snddevices.sh script.
What is in /proc/asound/devices?
[mrmachine@localhost mrmachine]$ cat /proc/asound/devices
4: [0- 0]: hardware dependent
8: [0- 0]: raw midi
18: [0- 2]: digital audio playback
26: [0- 2]: digital audio capture
25: [0- 1]: digital audio capture
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
0: [0- 0]: ctl
1: : sequencer
6: [0- 2]: hardware dependent
9: [0- 1]: raw midi
10: [0- 2]: raw midi
33: : timer
how's that look (this is after re-installing the patched driver and
running the snddevices.sh script).
shayne
8:14 p.m.
On Fri, 2005-01-21 at 10:19 +1100, Shayne O'Connor wrote:
Lee Revell wrote:
That's wrong. You must have ALSA built into your kernel and it's
interfering. Or you didn't apply the patch correctly. It should look
like this:
4: [0- 0]: hardware dependent
9: [0- 1]: raw midi
8: [0- 0]: raw midi
19: [0- 3]: digital audio playback <--- *** this is the device you are missing
18: [0- 2]: digital audio playback
26: [0- 2]: digital audio capture
25: [0- 1]: digital audio capture
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
0: [0- 0]: ctl
1: : sequencer
6: [0- 2]: hardware dependent
10: [0- 2]: raw midi
11: [0- 3]: raw midi
33: : timer
Lee
You're sure you have the correct ALSA modules
loaded? Maybe you have
ALSA modules built into the kernel that are interfering. Or maybe you
need to run the snddevices.sh script.
What is in /proc/asound/devices?
[mrmachine@localhost mrmachine]$ cat /proc/asound/devices
4: [0- 0]: hardware dependent
8: [0- 0]: raw midi
18: [0- 2]: digital audio playback
26: [0- 2]: digital audio capture
25: [0- 1]: digital audio capture
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
0: [0- 0]: ctl
1: : sequencer
6: [0- 2]: hardware dependent
9: [0- 1]: raw midi
10: [0- 2]: raw midi
33: : timer
8:40 p.m.
Lee Revell wrote:
On Fri, 2005-01-21 at 10:19 +1100, Shayne O'Connor
wrote:
what's the proper way to apply the patch?
i cd'd to the alsa-driver source directory and did this:
"patch -p1 < ../emu10k1-multichannel-v002.patch"
and it gave output saying that it patched successfully.
then i did "make; sudo make install", ran the snddevices script, then ran:
"/sbin/modprobe snd-emu10k1;/sbin/modprobe snd-pcm-oss;/sbin/modprobe
snd-mixer-oss;/sbin/modprobe snd-seq-oss"
i'm using a fedora core 2 planet ccrma installation - the ccrma stuff
was installed over my original fc2 install via apt ... i think the
default fc2 install compiles alsa into the kernel, but the ccrma
packages build alsa as a module?
but, then again, i'm using the ccrma patched 2.6.10 kernel, so i don't
think that alsa would have been compiled into that version ...
maybe my problem was only re-compiling and installing the alsa-driver
package and not the others as well?
shayne
Lee Revell wrote:
That's wrong. You must have ALSA built into your kernel and it's
interfering. Or you didn't apply the patch correctly. It should look
like this:
You're sure you have the correct ALSA modules
loaded? Maybe you have
ALSA modules built into the kernel that are interfering. Or maybe you
need to run the snddevices.sh script.
What is in /proc/asound/devices?
[mrmachine@localhost mrmachine]$ cat /proc/asound/devices
4: [0- 0]: hardware dependent
8: [0- 0]: raw midi
18: [0- 2]: digital audio playback
26: [0- 2]: digital audio capture
25: [0- 1]: digital audio capture
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
0: [0- 0]: ctl
1: : sequencer
6: [0- 2]: hardware dependent
9: [0- 1]: raw midi
10: [0- 2]: raw midi
33: : timer
9:01 p.m.
On Fri, 2005-01-21 at 12:03 +1100, Shayne O'Connor wrote:
what's the proper way to apply the patch?
i cd'd to the alsa-driver source directory and did this:
"patch -p1 < ../emu10k1-multichannel-v002.patch"
and it gave output saying that it patched successfully.
then i did "make; sudo make install", ran the snddevices script, then ran:
"/sbin/modprobe snd-emu10k1;/sbin/modprobe snd-pcm-oss;/sbin/modprobe
snd-mixer-oss;/sbin/modprobe snd-seq-oss"
Well, if ALSA is installed as modules, you have to rmmod them all before
doing "modprobe snd-emu10k1".
Use lsmod to verify that all your ALSA modules are unloaded, then
install the patched ALSA modules and load them.
Lee
9:20 p.m.
On Thu, 2005-01-20 at 17:03, Shayne O'Connor wrote:
Lee Revell wrote:
:-) Both, see below...
On Fri, 2005-01-21 at 10:19 +1100, Shayne
O'Connor wrote:
what's the proper way to apply the patch?
i cd'd to the alsa-driver source directory and did this:
"patch -p1 < ../emu10k1-multichannel-v002.patch"
and it gave output saying that it patched successfully.
then i did "make; sudo make install", ran the snddevices script, then ran:
"/sbin/modprobe snd-emu10k1;/sbin/modprobe snd-pcm-oss;/sbin/modprobe
snd-mixer-oss;/sbin/modprobe snd-seq-oss"
i'm using a fedora core 2 planet ccrma installation - the ccrma stuff
was installed over my original fc2 install via apt ... i think the
default fc2 install compiles alsa into the kernel, but the ccrma
packages build alsa as a module? Lee Revell wrote:
That's wrong. You must have ALSA built into your kernel and it's
interfering. Or you didn't apply the patch correctly. It should look
like this:
You're sure you have the correct ALSA modules
loaded? Maybe you have
ALSA modules built into the kernel that are interfering. Or maybe you
need to run the snddevices.sh script.
What is in /proc/asound/devices?
[mrmachine@localhost mrmachine]$ cat /proc/asound/devices
4: [0- 0]: hardware dependent
8: [0- 0]: raw midi
18: [0- 2]: digital audio playback
26: [0- 2]: digital audio capture
25: [0- 1]: digital audio capture
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
0: [0- 0]: ctl
1: : sequencer
6: [0- 2]: hardware dependent
9: [0- 1]: raw midi
10: [0- 2]: raw midi
33: : timer but, then again, i'm using the ccrma patched
2.6.10 kernel, so i don't
think that alsa would have been compiled into that version ...
maybe my problem was only re-compiling and installing the alsa-driver
package and not the others as well?
Caveat: For a normal Planet CCRMA FC2/3 install there are two locations
for the ALSA kernel modules. One is the one that comes with the kernel
itself. But Planet CCRMA also supplies a more up to date version of
ALSA, and those kernel modules are installed in:
/lib/modules/`uname -r`/updates/
They override (ie: they are first in the modprobe search order) the ones
in the kernel. So if you do a normal alsa kernel modules install you
will overwrite the modules in the kernel tree, not the updates, and then
if you reload the module you will still get the one in the "updates"
directory.
So... you want to overwrite the updated modules, and you can do that by
supplying the proper flag to the alsa driver configure process:
--with-moddir=/lib/modules/KERNEL_VERSION/updates
With this added the install will overwrite the updated modules
(installed through the kernel-module-alsa package for your kernel
version). A subsequenct /sbin/depmod -a and /sbin/modprobe whatever
should bring in the new version (provided you unload the modules first,
of course).
-- Fernando
9:54 p.m.
New subject: [linux-audio-user] Edirol UM-1S no workie...
Hi, all. Back for another round of Linux audio...
I recently switched from Red Hat FC1 to Debian Sarge, kernel 2.6.8-11,
and am having trouble getting my MIDI interface -- USB Edirol UM-1S --
working. Perhaps someone could give a little advice?
I read here...
http://eca.cx/lau/2004/11/0557.html
...and tried blacklisting "usb-midi" and "snd-usb-audio" alternately,
but it made no difference. No workie, either way.
Here's some info...
yew:~# lsusb
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 003: ID 0582:0009 Roland Corp.
Bus 001 Device 002: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical
Bus 001 Device 001: ID 0000:0000
yew:~# pmidi -list
Port Client name Port name
yew:~#
yew:~# lsusb -v
...
Bus 001 Device 003: ID 0582:0009 Roland Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 8
idVendor 0x0582 Roland Corp.
idProduct 0x0009
bcdDevice 1.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 73
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
MaxPower 120mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
...
Any ideas?
-Erik
21 Jan
21 Jan
4:27 a.m.
New subject: [linux-audio-user] Edirol UM-1S no workie...
Erik Thorsson wrote:
I recently switched from Red Hat FC1 to Debian Sarge,
kernel 2.6.8-11,
and am having trouble getting my MIDI interface -- USB Edirol UM-1S --
working.
yew:~# pmidi -list
Port Client name Port name
Is the snd-usb-audio module loaded, and is it attached to the device
(see /proc/bus/usb/devices)? Is the snd-seq-midi module loaded?
Clemens
11:40 a.m.
New subject: [linux-audio-user] Edirol UM-1S no workie...
Thanks for the help, guys. I still can't get it to work. :( Here's
more info, based on your suggestions.
yew:~# cat /proc/bus/usb/devices
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=ff(vend.) Sub=00 Prot=ff MxPS= 8 #Cfgs= 1
P: Vendor=0582 ProdID=0009 Rev= 1.00
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=120mA
I: If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=00 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=00 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=00 Driver=snd-usb-audio
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 2 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=00 Driver=snd-usb-audio
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms
yew:~# lsmod | grep usb
snd_usb_audio 65120 0
snd_rawmidi 23204 2 snd_mpu401_uart,snd_usb_audio
snd_pcm 85384 3 snd_intel8x0,snd_usb_audio,snd_pcm_oss
snd 50660 13
snd_seq_oss,snd_seq_midi_event,snd_seq,snd_intel8x0,snd_ac97_codec,snd_mpu401_uart,snd_usb_audio,snd_rawmidi,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
usbhid 28864 0
usbcore 104164 5 snd_usb_audio,usbhid,ohci_hcd
yew:~#
yew:~# cat /proc/modules | grep snd_seq_midi
snd_seq_midi_event 7552 1 snd_seq_oss, Live 0xded53000
snd_seq 46480 4 snd_seq_oss,snd_seq_midi_event, Live 0xdedce000
snd 50660 13
snd_seq_oss,snd_seq_midi_event,snd_seq,snd_intel8x0,snd_ac97_codec,snd_mpu401_uart,snd_usb_audio,snd_rawmidi,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,
Live 0xded04000
yew:~#
Clemens Ladisch wrote:
Erik Thorsson wrote:
I recently switched from Red Hat FC1 to Debian
Sarge, kernel 2.6.8-11,
and am having trouble getting my MIDI interface -- USB Edirol UM-1S --
working.
yew:~# pmidi -list
Port Client name Port name
Is the snd-usb-audio module loaded, and is it attached to the device
(see /proc/bus/usb/devices)? Is the snd-seq-midi module loaded?
Clemens
1:51 p.m.
New subject: [linux-audio-user] Edirol UM-1S no workie...
Erik Thorsson wrote:
yew:~# cat /proc/bus/usb/devices
...
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=00 Driver=snd-usb-audio
...
So the correct driver is loaded. The ports should appear in the
output of "amidi -l".
yew:~# cat /proc/modules | grep snd_seq_midi
snd_seq_midi_event ...
...
snd-seq-midi is _not_ loaded. Try "modprobe snd-seq-midi".
This was a bug in some old ALSA version. Either running the modprobe
command at startup or updating to ALSA 1.0.8 should help.
HTH
Clemens
5:11 p.m.
New subject: [linux-audio-user] Edirol UM-1S no workie...
Thanks for your help, Clemens and David.
Re-installing ALSA (# apt-get install alsa) and running alsaconf did the
trick.
Added the 'modprobe snd-seq-midi' line to the Debian startup sequence,
following this guide: http://www.desktop-linux.net/debian-rclocal.htm
Now I get...
yew:/# amidi -l
Device Name
hw:1,0,0 UM-1 MIDI 1
yew:/# pmidi -l
Port Client name Port name
72:0 UM-1 - Rawmidi 1 UM-1 MIDI 1
yew:/#
Thanks again!
-E
Clemens Ladisch wrote:
Erik Thorsson wrote:
yew:~# cat /proc/bus/usb/devices
...
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=00 Driver=snd-usb-audio
...
So the correct driver is loaded. The ports should appear in the
output of "amidi -l".
yew:~# cat /proc/modules | grep snd_seq_midi
snd_seq_midi_event ...
...
snd-seq-midi is _not_ loaded. Try "modprobe snd-seq-midi".
This was a bug in some old ALSA version. Either running the modprobe
command at startup or updating to ALSA 1.0.8 should help.
HTH
Clemens
20 Jan
20 Jan
9:59 p.m.
Fernando Lopez-Lezcano wrote:
On Thu, 2005-01-20 at 17:03, Shayne O'Connor
wrote:
ok, thanx fernando, that would be the problem (stupid me - i just
pointed someone on the ccrma list today to those source directories) ...
now sorry to be a pain, but how do i unload the alsa modules? i've tried
a few things:
[root@localhost mrmachine]# /sbin/rmmod snd_emu10k1
ERROR: Module snd_emu10k1 is in use by snd_emu10k1_synth
[root@localhost mrmachine]# /sbin/rmmod snd_emu10k1_synth
[root@localhost mrmachine]# /sbin/rmmod snd_emu10k1
ERROR: Module snd_emu10k1 is in use by snd_emu10k1_synth
[root@localhost mrmachine]# /sbin/rmmod snd
ERROR: Module snd is in use by
snd_emu10k1_synth,snd_seq_midi,snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_oss,snd_seq_midi_event,snd_seq,snd_mixer_oss,snd_emu10k1,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm,snd_timer,snd_util_mem,snd_hwdep
would i have to comment these modules out in "modprobe.conf", reboot,
then install the patched alsa-driver, then reload them (as well as
uncomment them in modprobe.conf)?
shayne.
Lee Revell wrote:
:-) Both, see below...
On Fri, 2005-01-21 at 10:19 +1100, Shayne
O'Connor wrote:
what's the proper way to apply the patch?
i cd'd to the alsa-driver source directory and did this:
"patch -p1 < ../emu10k1-multichannel-v002.patch"
and it gave output saying that it patched successfully.
then i did "make; sudo make install", ran the snddevices script, then ran:
"/sbin/modprobe snd-emu10k1;/sbin/modprobe snd-pcm-oss;/sbin/modprobe
snd-mixer-oss;/sbin/modprobe snd-seq-oss"
i'm using a fedora core 2 planet ccrma installation - the ccrma stuff
was installed over my original fc2 install via apt ... i think the
default fc2 install compiles alsa into the kernel, but the ccrma
packages build alsa as a module?
Lee Revell wrote:
>You're sure you have the correct ALSA modules loaded? Maybe you have
>ALSA modules built into the kernel that are interfering. Or maybe you
>need to run the snddevices.sh script.
>
>What is in /proc/asound/devices?
>
>
>
[mrmachine@localhost mrmachine]$ cat /proc/asound/devices
4: [0- 0]: hardware dependent
8: [0- 0]: raw midi
18: [0- 2]: digital audio playback
26: [0- 2]: digital audio capture
25: [0- 1]: digital audio capture
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
0: [0- 0]: ctl
1: : sequencer
6: [0- 2]: hardware dependent
9: [0- 1]: raw midi
10: [0- 2]: raw midi
33: : timer
That's wrong. You must have ALSA built into your kernel and it's
interfering. Or you didn't apply the patch correctly. It should look
like this:
but, then again, i'm using the ccrma patched
2.6.10 kernel, so i don't
think that alsa would have been compiled into that version ...
maybe my problem was only re-compiling and installing the alsa-driver
package and not the others as well?
Caveat: For a normal Planet CCRMA FC2/3 install there are two locations
for the ALSA kernel modules. One is the one that comes with the kernel
itself. But Planet CCRMA also supplies a more up to date version of
ALSA, and those kernel modules are installed in:
/lib/modules/`uname -r`/updates/
They override (ie: they are first in the modprobe search order) the ones
in the kernel. So if you do a normal alsa kernel modules install you
will overwrite the modules in the kernel tree, not the updates, and then
if you reload the module you will still get the one in the "updates"
directory.
So... you want to overwrite the updated modules, and you can do that by
supplying the proper flag to the alsa driver configure process:
--with-moddir=/lib/modules/KERNEL_VERSION/updates
With this added the install will overwrite the updated modules
(installed through the kernel-module-alsa package for your kernel
version). A subsequenct /sbin/depmod -a and /sbin/modprobe whatever
should bring in the new version (provided you unload the modules first,
of course).
-- Fernando
21 Jan
21 Jan
12:18 a.m.
Shayne O'Connor wrote:
Fernando Lopez-Lezcano wrote:
ok, i did that and got the patched alsa working with "jackd -v -d alsa
-P hw:0,3 -C hw:0,2 -S".
i was able to connect clients such as ardour, muse and fweelin, but none
of them would record or play - they would freeze when trying to do so
and refuse to shut down. i've attatched the output from the jackd
terminal, just in case you can tell anything from it ...
On Thu, 2005-01-20 at 17:03, Shayne O'Connor
wrote:
ok, thanx fernando, that would be the problem (stupid me - i just
pointed someone on the ccrma list today to those source directories) ...
now sorry to be a pain, but how do i unload the alsa modules? i've tried
a few things:
[root@localhost mrmachine]# /sbin/rmmod snd_emu10k1
ERROR: Module snd_emu10k1 is in use by snd_emu10k1_synth
[root@localhost mrmachine]# /sbin/rmmod snd_emu10k1_synth
[root@localhost mrmachine]# /sbin/rmmod snd_emu10k1
ERROR: Module snd_emu10k1 is in use by snd_emu10k1_synth
[root@localhost mrmachine]# /sbin/rmmod snd
ERROR: Module snd is in use by
snd_emu10k1_synth,snd_seq_midi,snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_oss,snd_seq_midi_event,snd_seq,snd_mixer_oss,snd_emu10k1,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm,snd_timer,snd_util_mem,snd_hwdep
would i have to comment these modules out in "modprobe.conf", reboot,
then install the patched alsa-driver, then reload them (as well as
uncomment them in modprobe.conf)?
Lee Revell wrote:
:-) Both, see below...
On Fri, 2005-01-21 at 10:19 +1100, Shayne
O'Connor wrote:
>Lee Revell wrote:
>
>
>
>
>>You're sure you have the correct ALSA modules loaded? Maybe you have
>>ALSA modules built into the kernel that are interfering. Or maybe you
>>need to run the snddevices.sh script.
>>
>>What is in /proc/asound/devices?
>>
>>
>>
>>
>>
>[mrmachine@localhost mrmachine]$ cat /proc/asound/devices
>4: [0- 0]: hardware dependent
>8: [0- 0]: raw midi
>18: [0- 2]: digital audio playback
>26: [0- 2]: digital audio capture
>25: [0- 1]: digital audio capture
>16: [0- 0]: digital audio playback
>24: [0- 0]: digital audio capture
>0: [0- 0]: ctl
>1: : sequencer
>6: [0- 2]: hardware dependent
>9: [0- 1]: raw midi
>10: [0- 2]: raw midi
>33: : timer
>
>
>
>
That's wrong. You must have ALSA built into your kernel and it's
interfering. Or you didn't apply the patch correctly. It should look
like this:
what's the proper way to apply the patch?
i cd'd to the alsa-driver source directory and did this:
"patch -p1 < ../emu10k1-multichannel-v002.patch"
and it gave output saying that it patched successfully.
then i did "make; sudo make install", ran the snddevices script, then ran:
"/sbin/modprobe snd-emu10k1;/sbin/modprobe snd-pcm-oss;/sbin/modprobe
snd-mixer-oss;/sbin/modprobe snd-seq-oss"
i'm using a fedora core 2 planet ccrma installation - the ccrma stuff
was installed over my original fc2 install via apt ... i think the
default fc2 install compiles alsa into the kernel, but the ccrma
packages build alsa as a module?
but, then again, i'm using the ccrma patched
2.6.10 kernel, so i don't
think that alsa would have been compiled into that version ...
maybe my problem was only re-compiling and installing the alsa-driver
package and not the others as well?
Caveat: For a normal Planet CCRMA FC2/3 install there are two locations
for the ALSA kernel modules. One is the one that comes with the kernel
itself. But Planet CCRMA also supplies a more up to date version of
ALSA, and those kernel modules are installed in:
/lib/modules/`uname -r`/updates/
They override (ie: they are first in the modprobe search order) the ones
in the kernel. So if you do a normal alsa kernel modules install you
will overwrite the modules in the kernel tree, not the updates, and then
if you reload the module you will still get the one in the "updates"
directory.
So... you want to overwrite the updated modules, and you can do that by
supplying the proper flag to the alsa driver configure process:
--with-moddir=/lib/modules/KERNEL_VERSION/updates
With this added the install will overwrite the updated modules
(installed through the kernel-module-alsa package for your kernel
version). A subsequenct /sbin/depmod -a and /sbin/modprobe whatever
should bring in the new version (provided you unload the modules first,
of course).
-- Fernando
I am especially interested in
any regressions that impact regular PCM playback (the hw:0,0 device).
well, it is a cavalcade of xruns ...
when i run jackd using the hw:0 device and my usual command:
"/usr/bin/jackd -T -v -R -P60 -dalsa -dhw:0 -r41000 -p512 -n2 -S -i2 -o2"
i get an incessant string of xruns. i've tried changing some parameters,
but to no avail ... here's the brief output from dmesg:
[mrmachine@localhost mrmachine]$ dmesg
d_addr 3072
init voice - master 1 extra 0 start_addr 1024 end_addr 3072
init voice - master 0 extra 0 start_addr 1024 end_addr 3072
(these two lines repeat over and over, i guess each time an xrun occurs).
so i don't think this patch is workable for me yet :(
shayne
2:10 p.m.
On Fri, 2005-01-21 at 15:42 +1100, Shayne O'Connor wrote:
ok, i did that and got the patched alsa working with
"jackd -v -d alsa
-P hw:0,3 -C hw:0,2 -S".
i was able to connect clients such as ardour, muse and fweelin, but none
of them would record or play - they would freeze when trying to do so
and refuse to shut down. i've attatched the output from the jackd
terminal, just in case you can tell anything from it ...
OK, it looks like the patch is not quite ready for widespread use. I
will take a look at it. It looks like I need to change regular PCM
playback back to use the channel loop interrupt or tweak the timing a
little. It works for me but I do have an intermittent problem with
clients immediately zombifying.
Thanks for testing, I'll let you know when I have an updated patch.
Lee
I am especially interested in
any regressions that impact regular PCM playback (the hw:0,0 device).
well, it is a cavalcade of xruns ...
when i run jackd using the hw:0 device and my usual command:
"/usr/bin/jackd -T -v -R -P60 -dalsa -dhw:0 -r41000 -p512 -n2 -S -i2 -o2"
i get an incessant string of xruns. i've tried changing some parameters,
but to no avail ... here's the brief output from dmesg:
20 Jan
20 Jan
7:05 p.m.
Lee Revell wrote:
You're sure you have the correct ALSA modules
loaded? Maybe you have
ALSA modules built into the kernel that are interfering. Or maybe you
need to run the snddevices.sh script.
What is in /proc/asound/devices?
also, here's what's in modprobe.conf (it doesn't look much like the
recommended settings on the alsa emu10k1 page):
alias eth0 forcedeth
alias snd-card-0 snd-emu10k1
install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 &&
/usr/sbin/alsactl restore >/dev/null 2>&1 || :
remove snd-emu10k1 { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-emu10k1
alias usb-controller ehci-hcd
alias usb-controller1 ohci-hcd
alias char-major-195* nvidia
shayne
21 Jan
21 Jan
12:20 a.m.
woops ... here's the jackd output text
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect ardour:Audio 1/out 2 and ardour:master/in 2 (self)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
clear connections for ardour:master/in 1
DIS-connect ardour:Audio 1/out 1 and ardour:master/in 1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
clear connections for ardour:master/in 2
DIS-connect ardour:Audio 1/out 2 and ardour:master/in 2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect ardour:Audio 1/out 1 and ardour:master/in 1 (self)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect ardour:Audio 1/out 2 and ardour:master/in 2 (self)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect ardour:master/out 1 and alsa_pcm:playback_1 (output)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect ardour:master/out 2 and alsa_pcm:playback_2 (output)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
ardour resigned as timebase master
clear connections for ardour:master/in 1
DIS-connect ardour:Audio 1/out 1 and ardour:master/in 1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
clear connections for ardour:master/in 2
DIS-connect ardour:Audio 1/out 2 and ardour:master/in 2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect alsa_pcm:capture_1 and ardour:master/in 1 (forward)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect alsa_pcm:capture_2 and ardour:master/in 2 (forward)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
clear connections for ardour:master/in 1
DIS-connect alsa_pcm:capture_1 and ardour:master/in 1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
clear connections for ardour:master/in 2
DIS-connect alsa_pcm:capture_2 and ardour:master/in 2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect alsa_pcm:capture_3 and ardour:master/in 1 (forward)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect alsa_pcm:capture_4 and ardour:master/in 2 (forward)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
clear connections for ardour:master/in 1
DIS-connect alsa_pcm:capture_3 and ardour:master/in 1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
clear connections for ardour:master/in 2
DIS-connect alsa_pcm:capture_4 and ardour:master/in 2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect alsa_pcm:capture_1 and ardour:master/in 1 (forward)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect alsa_pcm:capture_2 and ardour:master/in 2 (forward)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
cannot read event response from client [ardour] (Connection reset by peer)
bad status for client event handling (type = 8)
removing disconnected client ardour state = Not triggered errors = 2
removing client "ardour"
removing client "ardour" from the processing chain
DIS-connect alsa_pcm:capture_1 and ardour:Audio 1/in 1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect ardour:click/out 1 and alsa_pcm:playback_1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect ardour:master/out 2 and alsa_pcm:playback_2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect ardour:master/out 1 and alsa_pcm:playback_1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect alsa_pcm:capture_2 and ardour:master/in 2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect alsa_pcm:capture_1 and ardour:master/in 1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect ardour:auditioner/out 2 and alsa_pcm:playback_2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect ardour:auditioner/out 1 and alsa_pcm:playback_1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
sync poll interrupted for client 2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
-- jack_rechain_graph()
new client: ardour, id = 3 type 2 @ 0xb6672000 fd = 10
polling sync client 3
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
registered port ardour:auditioner/out 1, offset = 69632
connect ardour:auditioner/out 1 and alsa_pcm:playback_1 (output)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
registered port ardour:auditioner/out 2, offset = 73728
connect ardour:auditioner/out 2 and alsa_pcm:playback_2 (output)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
registered port ardour:master/in 1, offset = 0
registered port ardour:master/in 2, offset = 0
registered port ardour:master/out 1, offset = 77824
registered port ardour:master/out 2, offset = 81920
registered port ardour:click/out 1, offset = 86016
registered port ardour:Audio 1/in 1, offset = 0
registered port ardour:Audio 1/out 1, offset = 90112
registered port ardour:Audio 1/out 2, offset = 94208
connect ardour:click/out 1 and alsa_pcm:playback_1 (output)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect alsa_pcm:capture_1 and ardour:Audio 1/in 1 (forward)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect ardour:Audio 1/out 1 and ardour:master/in 1 (self)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect ardour:Audio 1/out 2 and ardour:master/in 2 (self)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
clear connections for ardour:master/in 1
DIS-connect ardour:Audio 1/out 1 and ardour:master/in 1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
clear connections for ardour:master/in 2
DIS-connect ardour:Audio 1/out 2 and ardour:master/in 2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect ardour:Audio 1/out 1 and ardour:master/in 1 (self)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect ardour:Audio 1/out 2 and ardour:master/in 2 (self)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect ardour:master/out 1 and alsa_pcm:playback_1 (output)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect ardour:master/out 2 and alsa_pcm:playback_2 (output)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
clear connections for ardour:master/in 1
DIS-connect ardour:Audio 1/out 1 and ardour:master/in 1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
clear connections for ardour:master/in 2
DIS-connect ardour:Audio 1/out 2 and ardour:master/in 2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect alsa_pcm:capture_1 and ardour:master/in 1 (forward)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect alsa_pcm:capture_2 and ardour:master/in 2 (forward)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
cannot send event to client [ardour] (Broken pipe)
bad status for client event handling (type = 8)
removing disconnected client ardour state = Not triggered errors = 2
removing client "ardour"
removing client "ardour" from the processing chain
DIS-connect alsa_pcm:capture_1 and ardour:Audio 1/in 1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect ardour:click/out 1 and alsa_pcm:playback_1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect ardour:master/out 2 and alsa_pcm:playback_2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect ardour:master/out 1 and alsa_pcm:playback_1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect alsa_pcm:capture_2 and ardour:master/in 2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect alsa_pcm:capture_1 and ardour:master/in 1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect ardour:auditioner/out 2 and alsa_pcm:playback_2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect ardour:auditioner/out 1 and alsa_pcm:playback_1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client ardour: start_fd=5, execution_order=0.
client ardour: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
sync poll interrupted for client 3
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
-- jack_rechain_graph()
new client: MusE-1, id = 4 type 2 @ 0xb6672000 fd = 10
registered port MusE-1:Input 1-0, offset = 0
registered port MusE-1:Input 1-1, offset = 0
registered port MusE-1:Out 1-0, offset = 69632
registered port MusE-1:Out 1-1, offset = 73728
polling sync client 4
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client MusE-1: start_fd=5, execution_order=0.
client MusE-1: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect MusE-1:Out 1-0 and alsa_pcm:playback_1 (output)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client MusE-1: start_fd=5, execution_order=0.
client MusE-1: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect MusE-1:Out 1-0 and alsa_pcm:playback_2 (output)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client MusE-1: start_fd=5, execution_order=0.
client MusE-1: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect MusE-1:Out 1-0 and alsa_pcm:playback_2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client MusE-1: start_fd=5, execution_order=0.
client MusE-1: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect MusE-1:Out 1-0 and alsa_pcm:playback_1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client MusE-1: start_fd=5, execution_order=0.
client MusE-1: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
sync poll interrupted for client 4
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
-- jack_rechain_graph()
registered port MusE-1:Input 1-0, offset = 0
registered port MusE-1:Input 1-1, offset = 0
registered port MusE-1:Out 1-0, offset = 73728
registered port MusE-1:Out 1-1, offset = 69632
polling sync client 4
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client MusE-1: start_fd=5, execution_order=0.
client MusE-1: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect MusE-1:Out 1-0 and alsa_pcm:playback_1 (output)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client MusE-1: start_fd=5, execution_order=0.
client MusE-1: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
connect MusE-1:Out 1-0 and alsa_pcm:playback_2 (output)
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client MusE-1: start_fd=5, execution_order=0.
client MusE-1: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect MusE-1:Out 1-0 and alsa_pcm:playback_2
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client MusE-1: start_fd=5, execution_order=0.
client MusE-1: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect MusE-1:Out 1-0 and alsa_pcm:playback_1
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client MusE-1: start_fd=5, execution_order=0.
client MusE-1: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
sync poll interrupted for client 4
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
-- jack_rechain_graph()
removing disconnected client MusE-1 state = Not triggered errors = 0
removing client "MusE-1"
removing client "MusE-1" from the processing chain
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
-- jack_rechain_graph()
when i run jackd using the hw:0 device and my usual command:
"/usr/bin/jackd -T -v -R -P60 -dalsa -dhw:0 -r41000 -p512 -n2 -S -i2 -o2"
i get an incessant string of xruns. i've tried changing some parameters, but to no
avail ... here's the brief output from dmesg:
[mrmachine@localhost mrmachine]$ dmesg
d_addr 3072
init voice - master 1 extra 0 start_addr 1024 end_addr 3072
init voice - master 0 extra 0 start_addr 1024 end_addr 3072
(these two lines repeat over and over, i guess each time an xrun occurs).
1:29 p.m.
On Fri, 2005-01-21 at 15:44 +1100, Shayne O'Connor wrote:
when i run jackd using the hw:0 device and my usual
command:
"/usr/bin/jackd -T -v -R -P60 -dalsa -dhw:0 -r41000 -p512 -n2 -S -i2 -o2"
You can't run at 41000 (or 44100 which is what I think you meant to
write). This only works at 48000Hz (just like kX ASIO, because it's a
hardware restriction)
Lee
4:52 p.m.
Lee Revell wrote:
On Fri, 2005-01-21 at 15:44 +1100, Shayne O'Connor
wrote:
oops - that is what i meant to write :)
but i probly should've been more clear - i tried my usual start-up
command on hw:0 (with the 44100 rate) in *addition* to trying it at
48000 ... same result (avalanche of x-runs).
i meant to say that i tried (pretty much) all settings (different sample
rates, buffer periods, memory lock/no memory lock) but nothing would get
rid of them x-runs on hw:0 - not even a sample-rate of 48000.
i've heard a lot of negative stuff about creative's native (?) 48000Hz
sampling rate - not being too technically adept, i'm wondering what is
really going on ... is *everything* put in through the ac97 codec
(that's the input port, no?) sampled at that rate? what does this mean
if i'm always setting jack (without the patched alsa) to record at
44100Hz? i know that things start sounding funny if you record at 48000
and then playback/downsample to a different rate .....
should i *always* be using 48000Hz when recording on an emu10k1 card? if
so, what's the best way to get a finished project down to CD-style
44100Hz without making it sound wierd?
shayne
when i run jackd using the hw:0 device and my
usual command:
"/usr/bin/jackd -T -v -R -P60 -dalsa -dhw:0 -r41000 -p512 -n2 -S -i2 -o2"
You can't run at 41000 (or 44100 which is what I think you meant to
write). This only works at 48000Hz (just like kX ASIO, because it's a
hardware restriction)
Lee
5:39 p.m.
On Sat, 2005-01-22 at 08:17 +1100, Shayne O'Connor wrote:
oops - that is what i meant to write :)
but i probly should've been more clear - i tried my usual start-up
command on hw:0 (with the 44100 rate) in *addition* to trying it at
48000 ... same result (avalanche of x-runs).
i meant to say that i tried (pretty much) all settings (different sample
rates, buffer periods, memory lock/no memory lock) but nothing would get
rid of them x-runs on hw:0 - not even a sample-rate of 48000.
OK. I cannot reproduce your problem. It works fine for me at all of
the above settings, even 44100. I will revert the PCM handling to the
old method and see if this works for you.
i've heard a lot of negative stuff about creative's native (?) 48000Hz
sampling rate - not being too technically adept, i'm wondering what is
really going on ... is *everything* put in through the ac97 codec
(that's the input port, no?) sampled at that rate? what does this mean
if i'm always setting jack (without the patched alsa) to record at
44100Hz? i know that things start sounding funny if you record at 48000
and then playback/downsample to a different rate .....
The DSP runs at 48000 natively, and does hardware sample rate conversion
for all other rates. The exception is multichannel recording, which
only works at 16bit, 48000Hz, because you are directly capturing the
outputs of the internal DSP before it goes through any rate conversion.
Also, there is only one stereo sample rate converter for capture, while
for playback each of the 64 voices has its own SRC.
These hardware SRCs are good quality, because emu10k1 is really a
hardware synthesizer that also can do PCM, the exact same hardware is
used for pitch shifting by the synth as sample rate conversion for PCM.
In practice there are some bugs but these can be worked around in the
driver.
should i *always* be using 48000Hz when recording on
an emu10k1 card? if
so, what's the best way to get a finished project down to CD-style
44100Hz without making it sound wierd?
The best way to use this card is to run at 48000HZ and then when you are
done resample to 44100 using a high quality software resampler. OTOH,
if you are working with a bunch of 44100Hz samples, you can run JACK at
44100Hz, if it sounds good to you. Multichannel playback at 44100
should be supported eventually. Although, keep in mind the kX driver
doesn't support this yet, and they have docs from Creative. But you
won't get the multichannel recording functionality at this samplerate.
If you are using it for live recording or effects processing then you
should certainly run at 48000.
Lee
23 Jan
23 Jan
1:40 a.m.
Lee Revell wrote:
thankyou very much - very clear and informative!
shayne
i've heard
a lot of negative stuff about creative's native (?) 48000Hz
sampling rate - not being too technically adept, i'm wondering what is
really going on ... is *everything* put in through the ac97 codec
(that's the input port, no?) sampled at that rate? what does this mean
if i'm always setting jack (without the patched alsa) to record at
44100Hz? i know that things start sounding funny if you record at 48000
and then playback/downsample to a different rate .....
The DSP runs at 48000 natively, and does hardware sample rate conversion
for all other rates. The exception is multichannel recording, which
only works at 16bit, 48000Hz, because you are directly capturing the
outputs of the internal DSP before it goes through any rate conversion.
Also, there is only one stereo sample rate converter for capture, while
for playback each of the 64 voices has its own SRC.
These hardware SRCs are good quality, because emu10k1 is really a
hardware synthesizer that also can do PCM, the exact same hardware is
used for pitch shifting by the synth as sample rate conversion for PCM.
In practice there are some bugs but these can be worked around in the
driver.
should i *always* be using 48000Hz when recording
on an emu10k1 card? if
so, what's the best way to get a finished project down to CD-style
44100Hz without making it sound wierd?
The best way to use this card is to run at 48000HZ and then when you are
done resample to 44100 using a high quality software resampler. OTOH,
if you are working with a bunch of 44100Hz samples, you can run JACK at
44100Hz, if it sounds good to you. Multichannel playback at 44100
should be supported eventually. Although, keep in mind the kX driver
doesn't support this yet, and they have docs from Creative. But you
won't get the multichannel recording functionality at this samplerate.
If you are using it for live recording or effects processing then you
should certainly run at 48000.
Lee
21 Jan
21 Jan
11:16 p.m.
On Sat, 2005-01-22 at 08:17 +1100, Shayne O'Connor wrote:
but i probly should've been more clear - i tried
my usual start-up
command on hw:0 (with the 44100 rate) in *addition* to trying it at
48000 ... same result (avalanche of x-runs).
Please try the new version. I believe I have fixed this bug.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v004.patch
Lee
22 Jan
22 Jan
10:28 a.m.
Lee Revell wrote:
On Sat, 2005-01-22 at 08:17 +1100, Shayne O'Connor
wrote:
this patch works well
- no xruns using hw:0 at 48000 or 44100 .... runs exactly as i was using
it pre-patch.
- using your "quickstart" command, i was able to connect hydrogen and
ardour to jack and record a few bars of hums (multi-tracked hums, at
that) into ardour with no problems. there were a few xruns when loading
up ardour and loading a song, but that's normal isn't it?
- wavetable synth is back in action, too ...
i was gonna just apply this new patch, give it a go, and then uninstall
it - but seeing as it seems to work exactly as before on the default
(hw:0) device, and that it introduces a new, capabilities-laden device,
i'm gonna leave it there :)
this is quite impressive! keep it up!
... now to try and get ld10k1 installed (i think the current - last? -
version is incompatible with sb live) ...
shayne
but i probly should've been more clear - i
tried my usual start-up
command on hw:0 (with the 44100 rate) in *addition* to trying it at
48000 ... same result (avalanche of x-runs).
Please try the new version. I believe I have fixed this bug.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v004.patch
Lee
4:40 p.m.
On Sun, 2005-01-23 at 01:54 +1100, Shayne O'Connor wrote:
Great! Thanks for testing this. I think this patch will be included in
ALSA 1.0.9 if no other bugs are found.
This also seems to solve the problem causing complete system lockup when
using a period size less than 128 frames.
Lee
Please try the
new version. I believe I have fixed this bug.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v004.patch
Lee
this patch works well
- no xruns using hw:0 at 48000 or 44100 .... runs exactly as i was using
it pre-patch.
- using your "quickstart" command, i was able to connect hydrogen and
ardour to jack and record a few bars of hums (multi-tracked hums, at
that) into ardour with no problems. there were a few xruns when loading
up ardour and loading a song, but that's normal isn't it?
- wavetable synth is back in action, too ...
i was gonna just apply this new patch, give it a go, and then uninstall
it - but seeing as it seems to work exactly as before on the default
(hw:0) device, and that it introduces a new, capabilities-laden device,
i'm gonna leave it there :)
this is quite impressive! keep it up!
... now to try and get ld10k1 installed (i think the current - last? -
version is incompatible with sb live) ...
25 Jan
25 Jan
12:20 a.m.
Lee Revell wrote:
On Sun, 2005-01-23 at 01:54 +1100, Shayne O'Connor
wrote:
Great! Thanks for testing this. I think this patch will be included in
ALSA 1.0.9 if no other bugs are found.
This also seems to solve the problem causing complete system lockup when
using a period size less than 128 frames.
hi lee,
well, things are going *absolutely magnificently* with your emu10k1
patch - i haven't really tested it at 128 frames, but it works
brilliantly at 256 (i've tested it running ardour, hydrogen, muse, and
two vst plugins + vkeybd at the same time - incredible!).
my only problem, now that i've sort of got the hang of things, is
recording - i don't seem to be able to isolate the ac97 input as before
... when i try to record guitar or vocals over other tracks in ardour,
it keeps mixing the pre-recorded stuff with the line input stuff!! i'm
sure it's just a mixer setting i have to adjust, but i don't know which
.... it certainly doesn't seem to be the same adjustments i had to make
before the patch?
so, can you tell me how to isolate the ac97 channel?
(in qjackctl, i have only inputs 1 + 2 connected, going into ardour's
inputs - not sure if these are the right two out of the 16 on offer).
cheers
shayne
Please try
the new version. I believe I have fixed this bug.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v004.patch
Lee
this patch works well
- no xruns using hw:0 at 48000 or 44100 .... runs exactly as i was using
it pre-patch.
- using your "quickstart" command, i was able to connect hydrogen and
ardour to jack and record a few bars of hums (multi-tracked hums, at
that) into ardour with no problems. there were a few xruns when loading
up ardour and loading a song, but that's normal isn't it?
- wavetable synth is back in action, too ...
i was gonna just apply this new patch, give it a go, and then uninstall
it - but seeing as it seems to work exactly as before on the default
(hw:0) device, and that it introduces a new, capabilities-laden device,
i'm gonna leave it there :)
this is quite impressive! keep it up!
... now to try and get ld10k1 installed (i think the current - last? -
version is incompatible with sb live) ...
3:11 p.m.
On Tue, 2005-01-25 at 15:52 +1100, Shayne O'Connor wrote:
hi lee,
well, things are going *absolutely magnificently* with your emu10k1
patch - i haven't really tested it at 128 frames, but it works
brilliantly at 256 (i've tested it running ardour, hydrogen, muse, and
two vst plugins + vkeybd at the same time - incredible!).
Great! I have found it's usable at 128 frames on my slow (600Mhz) box.
64 frames "works" in that there are no xruns but the sound is completely
distorted. Maybe this would sound good on a faster machine or maybe
that's the lower limit of the hardware. Interestingly 128 frames is the
lowest latency the kX driver supports, although 256 seems to be the
lowest usable latency under Windows.
my only problem, now that i've sort of got the
hang of things, is
recording - i don't seem to be able to isolate the ac97 input as before
... when i try to record guitar or vocals over other tracks in ardour,
it keeps mixing the pre-recorded stuff with the line input stuff!! i'm
sure it's just a mixer setting i have to adjust, but i don't know which
.... it certainly doesn't seem to be the same adjustments i had to make
before the patch?
so, can you tell me how to isolate the ac97 channel?
Known problem. Currently it captures the 16 channels which correspond
to physical outputs, so you can't isolate an input for capture. This
setting is good for testing, you can connect meterbridge to all 16
outputs and monitor your output levels, which is handy if you want to
see which FX buses go to which outputs. But it's not practical. There
are 16 other channels that don't map to physical outputs, these only
record what you connect to them in the DSP manager. This are the
channels the kX driver uses for ASIO capture.
The next version will capture these channels by default, but this
requires an update to the default DSP configuration, because the current
DSP config doesn't connect anything to them. This way the multichannel
functionality will be usable without requiring ld10k1 to be installed.
Lee
30 Jan
30 Jan
6:55 p.m.
Hi Lee, hi all,
On Wednesday 19 January 2005 00:40, Lee Revell wrote:
As promised, here's an updated patch to add real
multichannel playback
support (and improved multichannel capture) to the emu10k1 driver.
I just got around to installing these patched drivers and I must say: Wow!
Thanks for giving me the long awaited opportunity to access the various
channels of my sblive!
Now I only need to learn how to use the effects on my card and I need to find
a livedrive or at least some plans how the connector on the card is built...
Attached is a snipped from my .asoundrc to use these cool features with
qjackctl which doesn't allow different devices for playback and recording...
Will do more tests tomorrow, at first I need some sleep,
Arnold
--
There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened.
-- Douglas Adams, The Restaurant at the End of the Universe
8:13 p.m.
Arnold Krille wrote:
Hi Lee, hi all,
On Wednesday 19 January 2005 00:40, Lee Revell wrote:
or, you can enter "hw:0,2" in the "Input Device" box and
"hw:0,3" in the
"Output Device" box in qjackctl.
using "Playback Only", i am able to get down to 64 frames/periods when
using Mixxx - got a couple of xruns in a half-hour session (this was
with network running azureus and some other stuff).
not sure if you're aware, but the latest patch is this one:
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v007.patch
i'm not sure if this fixes the wavetabel synth, though - i still can't
get any sounds from the sb live onboard synth .... i'm gonna report back
to lee on the alsa-devel list, as that is probly the best place for
testing results, bug reports etc ...
shayne
As promised, here's an updated patch to add
real multichannel playback
support (and improved multichannel capture) to the emu10k1 driver.
I just got around to installing these patched drivers and I must say: Wow!
Thanks for giving me the long awaited opportunity to access the various
channels of my sblive!
Now I only need to learn how to use the effects on my card and I need to find
a livedrive or at least some plans how the connector on the card is built...
Attached is a snipped from my .asoundrc to use these cool features with
qjackctl which doesn't allow different devices for playback and recording...
Will do more tests tomorrow, at first I need some sleep,
Arnold
------------------------------------------------------------------------
ctl.sblive {
type hw
card 0
}
pcm.sblive {
type asym
playback.pcm {
type hw
card 0
device 3
}
capture.pcm {
type hw
card 0
device 2
}
}
9:21 p.m.
On Mon, 2005-01-31 at 11:56 +1100, Shayne O'Connor wrote:
using "Playback Only", i am able to get down
to 64 frames/periods when
using Mixxx - got a couple of xruns in a half-hour session (this was
with network running azureus and some other stuff).
not sure if you're aware, but the latest patch is this one:
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v007.patch
Actually I just remembered I posted a newer version. This connects the
external inputs to the multichannel capture device. The JACK capture
ports should correspond exactly to the default kX ASIO capture channels
(1,2 is Line/Mic, 9,10 is Line2/Mic2, etc), You can record from all
inputs at once, so with a LiveDrive you can record 4 or 6 analog inputs.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v008.patch
i'm not sure if this fixes the wavetabel synth,
though - i still can't
get any sounds from the sb live onboard synth .... i'm gonna report back
to lee on the alsa-devel list, as that is probly the best place for
testing results, bug reports etc ...
This is the first I have heard of it. The wavetable problem should have
been fixed a while ago. Please report it on alsa-devel.
Lee
31 Jan
31 Jan
5:09 a.m.
Lee Revell wrote:
my boo-boo - somewhere along the way my sfxload script got knocked out
of commission ... all is good now :)
shayne
ps - i'm sending this to alsa-devel as well, as it is probly more
appropriate there?
On Mon, 2005-01-31 at 11:56 +1100, Shayne O'Connor
wrote:
i'm sure i applied the patch correctly, but does this get rid of the
following problem? :
using "Playback Only", i am able to get
down to 64 frames/periods when
using Mixxx - got a couple of xruns in a half-hour session (this was
with network running azureus and some other stuff).
not sure if you're aware, but the latest patch is this one:
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v007.patch
Actually I just remembered I posted a newer version. This connects the
external inputs to the multichannel capture device. The JACK capture
ports should correspond exactly to the default kX ASIO capture channels
(1,2 is Line/Mic, 9,10 is Line2/Mic2, etc), You can record from all
inputs at once, so with a LiveDrive you can record 4 or 6 analog inputs.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v008.patch
The last version I posted had a stupid bug where it
captured
the 16 FX buses instead of the 16 external inputs like I had intended.
So you could only capture what you were playing back.
(btw - with this patch, i'm sure i've always been able to record from
the inputs *and* playback - the only problem is seperating the two so as
to only record the inputs through the ac97 codec, and not the playback
as well)
i'm not
sure if this fixes the wavetabel synth, though - i still can't
get any sounds from the sb live onboard synth .... i'm gonna report back
to lee on the alsa-devel list, as that is probly the best place for
testing results, bug reports etc ...
This is the first I have heard of it. The wavetable problem should have
been fixed a while ago. Please report it on alsa-devel.
3:46 p.m.
On Mon, 2005-01-31 at 20:53 +1100, Shayne O'Connor wrote:
Lee Revell wrote:
Yes version 008 should fix that problem. Please report it on alsa-devel
if you still have the problem with playback and capture being mixed.
Lee
On Mon, 2005-01-31 at 11:56 +1100, Shayne
O'Connor wrote:
i'm sure i applied the patch correctly, but does this get rid of the
following problem? :
using "Playback Only", i am able to get
down to 64 frames/periods when
using Mixxx - got a couple of xruns in a half-hour session (this was
with network running azureus and some other stuff).
not sure if you're aware, but the latest patch is this one:
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v007.patch
Actually I just remembered I posted a newer version. This connects the
external inputs to the multichannel capture device. The JACK capture
ports should correspond exactly to the default kX ASIO capture channels
(1,2 is Line/Mic, 9,10 is Line2/Mic2, etc), You can record from all
inputs at once, so with a LiveDrive you can record 4 or 6 analog inputs.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v008.patch
The last version I posted had a stupid bug where
it captured
the 16 FX buses instead of the 16 external inputs like I had intended.
So you could only capture what you were playing back.
(btw - with this patch, i'm sure i've always been able to record from
the inputs *and* playback - the only problem is seperating the two so as
to only record the inputs through the ac97 codec, and not the playback
as well)
3 Feb
3 Feb
2:44 p.m.
On Sun, 2005-01-30 at 20:21 -0500, Lee Revell wrote:
I posted a newer version. This connects the
external inputs to the multichannel capture device. The JACK capture
ports should correspond exactly to the default kX ASIO capture channels
(1,2 is Line/Mic, 9,10 is Line2/Mic2, etc), You can record from all
inputs at once, so with a LiveDrive you can record 4 or 6 analog inputs.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v008.patch
I have posted the latest version:
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v009.patch
- The multiple input capture feature described above was merged into
ALSA CVS, so this is no longer included in the patch. If you only need
the multichannel capture feature and not the playback, you can just use
ALSA CVS. I can't be certain of the mappings from inputs to JACK ports
on every possible card model, though it should be similar to the kX
driver. If in doubt, you can use meterbridge to monitor all 16 capture
channels.
- Split the snd_emu10k1_trigger_voice function into prepare_voice and
trigger_voice. This should improve the sync between multiple playback
channels. This behavior was derived from the opensource.creative.com
driver.
These improvements to the emu10k1 driver were made possible by a
donation from Mark Constable. If you find these patches useful, I
accept donations via my PayPal account.
Lee
16 Feb
16 Feb
3:15 p.m.
On Thu, 2005-02-03 at 13:44 -0500, Lee Revell wrote:
I have posted the latest version:
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v009.patch
The multichannel patches have been accepted into ALSA CVS. It will be
up to 24 hours before anonymous sourceforge CVS is in sync.
Thanks to everyone who tested this and reported bugs.
I would like to specifically thank Mikael Magnusson who reported a nasty
bug in the voice allocator, and Mark Constable who helped make these new
features possible with a PayPal donation.
Lee
26 Feb
26 Feb
8:40 p.m.
On Wed, 2005-02-16 at 14:14 -0500, Lee Revell wrote:
On Thu, 2005-02-03 at 13:44 -0500, Lee Revell wrote:
I have just posted an important bug fix for SBLive users to alsa-devel:
http://article.gmane.org/gmane.linux.alsa.devel/20090
The bug causes the multichannel capture device to capture the physical
outputs, rather than the inputs. It should be in ALSA CVS soon.
Here is a screenshot of this in action. I am using two meterbridge
instances to monitor the 16 ins and outs, and have connected inputs 11
and 12 (Line2/Mic2 on the LiveDrive) to outputs 1 and 2 (front
speakers).
http://www.alsa-project.org/~rlrevell/emu10k1-jack.png
Thanks to Shayne O'Connor who helped support this project with a PayPal
donation.
Lee
I have posted the latest version:
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v009.patch
The multichannel patches have been accepted into ALSA CVS. It will be
up to 24 hours before anonymous sourceforge CVS is in sync. 
30 Jan
30 Jan
8:22 p.m.
On Sun, 2005-01-30 at 23:54 +0100, Arnold Krille wrote:
Hi Lee, hi all,
On Wednesday 19 January 2005 00:40, Lee Revell wrote:
Thanks! I will be posting a new version soon that makes capture work
properly. The last version I posted had a stupid bug where it captured
the 16 FX buses instead of the 16 external inputs like I had intended.
So you could only capture what you were playing back. Good for testing
but not too useful.
As promised, here's an updated patch to add
real multichannel playback
support (and improved multichannel capture) to the emu10k1 driver.
I just got around to installing these patched drivers and I must say: Wow!
Thanks for giving me the long awaited opportunity to access the various
channels of my sblive!
Now I only need to learn how to use the effects on my card and I need to find
a livedrive or at least some plans how the connector on the card is built...
Attached is a snipped from my .asoundrc to use these
cool features with
qjackctl which doesn't allow different devices for playback and recording...
I though the same thing but actually qjackctl does support this. You
just have to select "Duplex" and manually type "hw:0,3" in the
Playback
box and "hw:0,2" in the Capture box. The current version of qjackctl
does not enumerate the ALSA devices for you, though this would be an
easy feature to add.
Lee
7213
days inactive
7252
days old
linux-audio-user@lists.linuxaudio.org
42 comments
6 participants
participants (6)
-
Arnold Krille -
Clemens Ladisch -
Erik Thorsson -
Fernando Lopez-Lezcano -
Lee Revell -
Shayne O'Connor