30 Apr
2003
30 Apr
'03
8:32 a.m.
Hi,
I am able to record using alsa/jackd/ardour with the analog input from
an AEB/4-I and plain pcm.rme9652 after tweaking /etc/asound.state by
hand for getting the internal input from the AEB working. jackd/ardour
works also very well with the PCI 128 only, even at period size 64.
Now, I want to record with the RME and having analog playback through
the PCI 128. Is this possible?
If yes, how to setup .asoundrc? I have been trying many combinations
of multi and ttable settings, but honestly, I do not fully understand
the syntax and semantics of alsa configurations.
I am using kernel and alsa-0.9.0 from a recent PlanetCCRMA
distribution, which is really a piece of gold.
BTW, after fumbling around with my own kernel patching, I ended always
with a complete freeze of ardour, when running jackd in realtime mode.
Here is, what aplay says:
[root@ardour root]# aplay -l
card 0: AudioPCI [Ensoniq AudioPCI], device 0: ES1371/1 [ES1371 DAC2/ADC]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: AudioPCI [Ensoniq AudioPCI], device 1: ES1371/2 [ES1371 DAC1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: 15 [RME Digi9636 (Rev 1.5)], device 0: RME Digi9636 (Rev 1.5)
[RME Digi9636 (Rev 1.5)]
Subdevices: 1/1
Subdevice #0: subdevice #0
[root@ardour root]# aplay -v -D hw:1,0
/usr/share/tuxracer/sounds/tux_on_rock1.wav
Playing WAVE '/usr/share/tuxracer/sounds/tux_on_rock1.wav' : Signed 16
bit Little Endian, Rate 44100 Hz, Stereo
aplay: set_params:789: Access type not available
Pretty strange, since ardour does not complain, when trying to
playback with the RME. Someone stated, that ardour ist writing
directly to the hardware, and seems to have no problem, when there's
nothing connected to the cards digital outputs. I also don't dare
trying to understand, why there is one capture/playback device in
/proc/card1/dev for the RME, while ardour reports 18.
Since I do not want to purchase another AEB/4-O analog output box, I
would really like to know, how I could use my cheapo SoundBlaster.
Thanks for your help
Martin
30 Apr
30 Apr
9:23 a.m.
On Wed, Apr 30, 2003 at 12:21:47 +0200, Martin Buechler wrote:
Pretty strange, since ardour does not complain, when
trying to
playback with the RME. Someone stated, that ardour ist writing
directly to the hardware, and seems to have no problem, when there's
nothing connected to the cards digital outputs. I also don't dare
trying to understand, why there is one capture/playback device in
/proc/card1/dev for the RME, while ardour reports 18.
That is because all the RMEs channels appear as one device.
Since I do not want to purchase another AEB/4-O analog
output box, I
would really like to know, how I could use my cheapo SoundBlaster.
You cant easily because the soundblaster and RME (unless you have wordclocked
them) will be running out of sync. If you did manage to make a virtual
device that read from the RME and wrote to the SB you would get lots of
clicks and pops.
If you want a cheaper solution and your not as worried about sound quality
(which i guiess is true if your willing to use a sb) you could by a cheap
ADAT/SPDIF DA converter and connect that to the rme.
- Steve
8:13 p.m.
New subject: [linux-audio-user] Capture with DIGI9636 Hammerfall Light and playback with PCI 128
On Wed, 2003-04-30 at 07:13, Steve Harris wrote:
You cant easily because the soundblaster and RME (unless you have wordclocked
them) will be running out of sync. If you did manage to make a virtual
device that read from the RME and wrote to the SB you would get lots of
clicks and pops.
Is this still an issue if all the recording is with one card and all the
playback is through the other card? And all the playback, at least, is
analog? I don't see where the problem would come from in that situation.
--
sigmotto: Liberty is theft.
1 May
1 May
12:05 p.m.
New subject: [linux-audio-user] Capture with DIGI9636 Hammerfall Light andplayback with PCI 128
On Wed, 2003-04-30 at 07:13, Steve Harris wrote:
Paul,
I'm going to guess that the problem will be in the way the output data is
handed to the Sound Blaster. Let's say that the underlying sound system
(Alsa or whatever) is running off of the RME's clock. The data is brought
into the system using the RME clock. It gets processed in the Linux
environment using the RME clock, and it gets handed, as a block of data, to
the Sound Blaster using the RME clock. This is the problem I think. The
sound Blaster needs to have the block handed to it based on it's own clock
rate. If not, then there will be times when the SB clock comes a little bit
early and the data won't be ready to go since the RME clock hasn't happened
yet. This will result in a click.
I hope this helps.
Mark
You cant easily because the soundblaster and RME (unless you
have wordclocked
them) will be running out of sync. If you did
manage to make a virtual
device that read from the RME and wrote to the SB you would get lots of
clicks and pops.
Is this still an issue if all the recording is with one card and all the
playback is through the other card? And all the playback, at least, is
analog? I don't see where the problem would come from in that situation.
3:31 p.m.
New subject: [linux-audio-user] Capture with DIGI9636 Hammerfall Light andplayback with PCI 128
Mark,
Thanks, your message did indeed suggest to me a way that using different
sound cards for input and output makes things more complicated for the
sound system. Only if the input analog-to-digital converter (ADC) and
the output digital-to-analog (DAC) use the same clock, will the number
of input samples available for reading match the number of output
samples that should be written, over a given span of time. If there are
two clocks, one will be slightly faster than the other. If some sound
processing application is in a loop of reading X number of samples,
processing them, and then writing X number of (different) samples,
eventually the faster interface has to wait for the slower one to catch
up. Waiting means lost samples, and lost samples sometimes cause audible
clicks or pops.
On Thu, 2003-05-01 at 09:54, Mark Knecht wrote:
--
sigmotto: Liberty is theft.
On Wed,
2003-04-30 at 07:13, Steve Harris wrote:
Paul,
I'm going to guess that the problem will be in the way the output data is
handed to the Sound Blaster. Let's say that the underlying sound system
(Alsa or whatever) is running off of the RME's clock. The data is brought
into the system using the RME clock. It gets processed in the Linux
environment using the RME clock, and it gets handed, as a block of data, to
the Sound Blaster using the RME clock. This is the problem I think. The
sound Blaster needs to have the block handed to it based on it's own clock
rate. If not, then there will be times when the SB clock comes a little bit
early and the data won't be ready to go since the RME clock hasn't happened
yet. This will result in a click.
I hope this helps.
Mark
You cant easily because the soundblaster and RME (unless you
have wordclocked
them) will be running out of sync. If you did
manage to make a virtual
device that read from the RME and wrote to the SB you would get lots of
clicks and pops.
Is this still an issue if all the recording is with one card and all the
playback is through the other card? And all the playback, at least, is
analog? I don't see where the problem would come from in that situation.
4:08 p.m.
New subject: [linux-audio-user] Capture with DIGI9636 Hammerfall Lightandplayback with PCI 128
Mark,
Thanks, your message did indeed suggest to me a way that using different
sound cards for input and output makes things more complicated for the
sound system. Only if the input analog-to-digital converter (ADC) and
the output digital-to-analog (DAC) use the same clock, will the number
of input samples available for reading match the number of output
samples that should be written, over a given span of time. If there are
two clocks, one will be slightly faster than the other. If some sound
processing application is in a loop of reading X number of samples,
processing them, and then writing X number of (different) samples,
eventually the faster interface has to wait for the slower one to catch
up. Waiting means lost samples, and lost samples sometimes cause audible
clicks or pops.
Paul,
You're completely on top of the problem now. The 'normal' way to get
around this problem. as Steve suggested earlier, is to use a common clock.
This is not necessarily impossible with your cards, but would take some
work. At the studio level there are fancy, expensive clocks, like 'Word
Clock', but that may not be necessary for your application.
The 9636 has a s/pdif output. s/pdif carries a clock. Many Sound Blaster
boards have s/pdif inputs. Since s/pdif carries a clock, if you can
configure the Sound Blaster to use s/pdif as it's clock source, and you hook
a cable from the s/pdif output on the RME to the s/pdif input on the Sound
Blaster, then conceptually they will both run locked together.
I have done this with my Digi 001, RME HDSP 9652 and my RME 9636, all
operating under Windows where I have drivers and configuration tools that
allow control over this sort of thing, but using the ADAT path instead of
s/pdif. It works well. Unfortunately, Linux configuration tools are not
always supporting all the features of different cards, so you would have to
figure out whether this stuff would work for you.
Thomas recently did a little app called hdspconf which allows you to set
the clock source on the RME card. This could work for you if you used the
Sound Blaster as the master and the RME as the slave. I noticed some funny
effects when doing this myself, so I think you'd just have to try it
yourself and see how it goes.
So, I think there may be solutions if you're willing to dig in a bit.
Good luck,
Mark
7871
days inactive
7872
days old
linux-audio-user@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
Mark Knecht -
Martin Buechler -
Paul Perkins -
Steve Harris