15 Dec
2004
15 Dec
'04
4:54 a.m.
Hello -
I just installed a new HDSP multiface with PCI on a PlanetCCRMA/FC3
box, kernel 2.6.8.1-1.520.2vS7.ll, ALSA 1.07 (homemade rpms) and am
not seeing any output levels on HDSPmixer (bottom row) despite
actually hearing the signal I expect (sounds great).
Modules/firmware load beautifully, I can route signal with HDSPmixer
as expected, adjust levels, etc, just no visual feedback from the
outputs row either with vu levels or changing peak values.
Also on mixer channels that do show vu's (input and internal, top and
middle rows respectively) the yellow peak indicators appear only
randomly every 2-3 seconds or so, sort or popping around without any
clear relation to the signal peak. Something's not right here.
/sbin/lspci:
02:0d.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP (rev 0b)
cat /proc/pci:
Bus 2, device 13, function 0:
Class 0401: PCI device 10ee:3fc5 (rev 11).
IRQ 5.
Master Capable. Latency=255.
Non-prefetchable 32 bit memory at 0xec800000 [0xec80ffff].
"proc/interrupts says the card is on it's own interrupt, IRQ 5.
Kevin
15 Dec
15 Dec
11:33 a.m.
Hi,
Family member with the HDSP 9652 using the same kernel but using
Planet Alsa support. Possibly your RPMs might have something to do
with this?
To me this sounds like a firmware revision issue. Check with other
MultiFace users as to which revision they are using.
On Wed, 15 Dec 2004 03:54:06 -0500, Kevin Ernste <kevinernste(a)gmail.com> wrote:
Hello -
I just installed a new HDSP multiface with PCI on a PlanetCCRMA/FC3
box, kernel 2.6.8.1-1.520.2vS7.ll, ALSA 1.07 (homemade rpms) and am
not seeing any output levels on HDSPmixer (bottom row) despite
actually hearing the signal I expect (sounds great).
Modules/firmware load beautifully, I can route signal with HDSPmixer
as expected, adjust levels, etc, just no visual feedback from the
outputs row either with vu levels or changing peak values.
Seems a bit strange. Default operation on my copy is that the
input/top row routes nowhere, so for input audio I have to select
where you want it to go and bring the level up before I see anything
in the bottom row. Note that if you choose a route but do not bring
the level up on the top row then the next time you look it's not
selected.
Default operation for the internal audio is vertical routing.
1-internal goes to 1-output, 2-internal goes to 2-output, etc. Default
levels are set correctly for this. This way if you choose a default
app it routes to internal 1/2 and you see output 1/2 with the same
value. Hook your output D/A there and you get sound. (Supposedly!) ;-)
Also on mixer channels that do show vu's (input and internal, top and
middle rows respectively) the yellow peak indicators appear only
randomly every 2-3 seconds or so, sort or popping around without any
clear relation to the signal peak. Something's not right here.
I see the yellow peak about 1/4" above the top of the green VU moving
as the audio does.
/sbin/lspci:
02:0d.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP (rev 0b)
cat /proc/pci:
Bus 2, device 13, function 0:
Class 0401: PCI device 10ee:3fc5 (rev 11).
IRQ 5.
Master Capable. Latency=255.
Non-prefetchable 32 bit memory at 0xec800000 [0xec80ffff].
"proc/interrupts says the card is on it's own interrupt, IRQ 5.
Is it set non-threaded?
Kevin
- Mark
12:12 p.m.
On Wed, 2004-12-15 at 07:33 -0800, Mark Knecht wrote:
Hi,
Family member with the HDSP 9652 using the same kernel but using
Planet Alsa support. Possibly your RPMs might have something to do
with this?
To me this sounds like a firmware revision issue. Check with other
MultiFace users as to which revision they are using.
Also this could be an ALSA bug. There were some changes to the HDSP
driver not too long ago. Something related to mmap and the VU meters.
Lee
12:22 p.m.
On Wed, 15 Dec 2004 07:33:39 -0800, Mark Knecht <markknecht(a)gmail.com> wrote:
Hi,
Family member with the HDSP 9652 using the same kernel but using
Planet Alsa support. Possibly your RPMs might have something to do
with this?
I forgot to mention, I was seeing this behaviour using 1.06cvs from
Planet which is why I upgraded to 1.07, to see if it would make a
difference. The RPM's built smoothly, though it's certainly very
possible I missed something ;)
To me this sounds like a firmware revision issue. Check with other
MultiFace users as to which revision they are using.
That was my first thought. There are lots of references to firmware
issues on this list and elsewhere, I'll double-check on the version
and see if anyone is using it successfully.
Again for anyone with a multiface:
/proc/pci (says "rev 11"):
Bus 2, device 13, function 0:
Class 0401: PCI device 10ee:3fc5 (rev 11).
IRQ 5.
Master Capable. Latency=255.
Non-prefetchable 32 bit memory at 0xec800000 [0xec80ffff].
/sbin/lspci (says "rev 0b"):
02:0d.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP (rev 0b)
On Wed, 15 Dec 2004 03:54:06 -0500, Kevin Ernste <kevinernste(a)gmail.com> wrote:
Right. In my test I was playing a stereo soundfile internally (levels
come up on middle row 1 and 2) then choosing "AN 1+2" for both
channels, bringing up the sends, etc. I can hear the level as I raise
the stick, just no vu display on AN 1+2' (bottom row). Routing to
other spots like "Analog" does the same thing. You can hear it
perfectly, just no output levels.
Plugging a Mic in on analog in1 shows levels as well in the top row,
and raising the level for headphones one can hear the Mic signal, but
again no visible meters on output.
Hello -
I just installed a new HDSP multiface with PCI on a PlanetCCRMA/FC3
box, kernel 2.6.8.1-1.520.2vS7.ll, ALSA 1.07 (homemade rpms) and am
not seeing any output levels on HDSPmixer (bottom row) despite
actually hearing the signal I expect (sounds great).
Modules/firmware load beautifully, I can route signal with HDSPmixer
as expected, adjust levels, etc, just no visual feedback from the
outputs row either with vu levels or changing peak values.
Seems a bit strange. Default operation on my copy is that the
input/top row routes nowhere, so for input audio I have to select
where you want it to go and bring the level up before I see anything
in the bottom row. Note that if you choose a route but do not bring
the level up on the top row then the next time you look it's not
selected.
I see the yellow peak about 1/4" above the top of the green VU moving
as the audio does.
That's what I thought it should be doing. For example, playing a
steady -20 dB test tone from PD shows correct levels in green (middle
row), but the yellow peaks appear only intermittently, every few
seconds, and after appearing they fall gradually down as if there were
no signal in the channel any more.
I'll try it out again on a Windows box and see if something's up with
the card itself.
Kevin
12:43 p.m.
Hi,
From reading Ivica's and Lee's posts it appears lucky that I don't
have these problems. I don't know what else to say at this point but
I'll continue to watch the thread and write back if anything comes to
mind.
I doubt it will help but have you changed any of the meter settings
in hdspmixer? Maybe some of this would change with a different choice
there.
Good luck,
Mark
On Wed, 15 Dec 2004 11:22:27 -0500, Kevin Ernste <kevinernste(a)gmail.com> wrote:
On Wed, 15 Dec 2004 07:33:39 -0800, Mark Knecht
<markknecht(a)gmail.com> wrote:
Hi,
Family member with the HDSP 9652 using the same kernel but using
Planet Alsa support. Possibly your RPMs might have something to do
with this?
I forgot to mention, I was seeing this behaviour using 1.06cvs from
Planet which is why I upgraded to 1.07, to see if it would make a
difference. The RPM's built smoothly, though it's certainly very
possible I missed something ;)
To me this sounds like a firmware revision issue. Check with other
MultiFace users as to which revision they are using.
That was my first thought. There are lots of references to firmware
issues on this list and elsewhere, I'll double-check on the version
and see if anyone is using it successfully.
Again for anyone with a multiface:
/proc/pci (says "rev 11"):
Bus 2, device 13, function 0:
Class 0401: PCI device 10ee:3fc5 (rev 11).
IRQ 5.
Master Capable. Latency=255.
Non-prefetchable 32 bit memory at 0xec800000 [0xec80ffff].
/sbin/lspci (says "rev 0b"):
02:0d.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP (rev 0b)
On Wed, 15 Dec 2004 03:54:06 -0500, Kevin Ernste <kevinernste(a)gmail.com> wrote:
Right. In my test I was playing a stereo soundfile internally (levels
come up on middle row 1 and 2) then choosing "AN 1+2" for both
channels, bringing up the sends, etc. I can hear the level as I raise
the stick, just no vu display on AN 1+2' (bottom row). Routing to
other spots like "Analog" does the same thing. You can hear it
perfectly, just no output levels.
Plugging a Mic in on analog in1 shows levels as well in the top row,
and raising the level for headphones one can hear the Mic signal, but
again no visible meters on output.
Hello -
I just installed a new HDSP multiface with PCI on a PlanetCCRMA/FC3
box, kernel 2.6.8.1-1.520.2vS7.ll, ALSA 1.07 (homemade rpms) and am
not seeing any output levels on HDSPmixer (bottom row) despite
actually hearing the signal I expect (sounds great).
Modules/firmware load beautifully, I can route signal with HDSPmixer
as expected, adjust levels, etc, just no visual feedback from the
outputs row either with vu levels or changing peak values.
Seems a bit strange. Default operation on my copy is that the
input/top row routes nowhere, so for input audio I have to select
where you want it to go and bring the level up before I see anything
in the bottom row. Note that if you choose a route but do not bring
the level up on the top row then the next time you look it's not
selected.
I see the yellow peak about 1/4" above the top of the green VU moving
as the audio does.
That's what I thought it should be doing. For example, playing a
steady -20 dB test tone from PD shows correct levels in green (middle
row), but the yellow peaks appear only intermittently, every few
seconds, and after appearing they fall gradually down as if there were
no signal in the channel any more.
I'll try it out again on a Windows box and see if something's up with
the card itself.
Kevin
1:16 p.m.
This is a default and *only* behavior (at least in my case). Changing
settings makes no difference.
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
-----Original Message-----
From: linux-audio-user-bounces(a)music.columbia.edu [mailto:linux-audio-
user-bounces(a)music.columbia.edu] On Behalf Of Mark Knecht
Sent: Wednesday, December 15, 2004 11:44 AM
To: kevine(a)esm.rochester.edu; A list for linux audio users
Subject: Re: [linux-audio-user] HDSPmixer problem
Hi,
From reading Ivica's and Lee's posts it appears lucky that I don't
have these problems. I don't know what else to say at this point but
I'll continue to watch the thread and write back if anything comes to
mind.
I doubt it will help but have you changed any of the meter settings
in hdspmixer? Maybe some of this would change with a different choice
there.
Good luck,
Mark
On Wed, 15 Dec 2004 11:22:27 -0500, Kevin Ernste <kevinernste(a)gmail.com>
wrote:
<kevinernste(a)gmail.com> wrote:
Right. In my test I was playing a stereo soundfile internally (levels
come up on middle row 1 and 2) then choosing "AN 1+2" for both
channels, bringing up the sends, etc. I can hear the level as I raise
the stick, just no vu display on AN 1+2' (bottom row). Routing to
other spots like "Analog" does the same thing. You can hear it
perfectly, just no output levels.
Plugging a Mic in on analog in1 shows levels as well in the top row,
and raising the level for headphones one can hear the Mic signal, but
again no visible meters on output.
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004
On Wed, 15 Dec 2004 07:33:39 -0800, Mark Knecht
<markknecht(a)gmail.com>
wrote:
Hi,
Family member with the HDSP 9652 using the same kernel but using
Planet Alsa support. Possibly your RPMs might have something to do
with this?
I forgot to mention, I was seeing this behaviour using 1.06cvs from
Planet which is why I upgraded to 1.07, to see if it would make a
difference. The RPM's built smoothly, though it's certainly very
possible I missed something ;)
To me this sounds like a firmware revision issue. Check with other
MultiFace users as to which revision they are using.
That was my first thought. There are lots of references to firmware
issues on this list and elsewhere, I'll double-check on the version
and see if anyone is using it successfully.
Again for anyone with a multiface:
/proc/pci (says "rev 11"):
Bus 2, device 13, function 0:
Class 0401: PCI device 10ee:3fc5 (rev 11).
IRQ 5.
Master Capable. Latency=255.
Non-prefetchable 32 bit memory at 0xec800000 [0xec80ffff].
/sbin/lspci (says "rev 0b"):
02:0d.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP (rev 0b)
>
> On Wed, 15 Dec 2004 03:54:06 -0500, Kevin Ernste Hello -
I just installed a new HDSP multiface with PCI on a PlanetCCRMA/FC3
box, kernel 2.6.8.1-1.520.2vS7.ll, ALSA 1.07 (homemade rpms) and am
not seeing any output levels on HDSPmixer (bottom row) despite
actually hearing the signal I expect (sounds great).
Modules/firmware load beautifully, I can route signal with HDSPmixer
as expected, adjust levels, etc, just no visual feedback from the
outputs row either with vu levels or changing peak values.
Seems a bit strange. Default operation on my copy is that the
input/top row routes nowhere, so for input audio I have to select
where you want it to go and bring the level up before I see anything
in the bottom row. Note that if you choose a route but do not bring
the level up on the top row then the next time you look it's not
selected.
I see the yellow peak about 1/4" above the top of the green VU moving
as the audio does.
That's what I thought it should be doing. For example, playing a
steady -20 dB test tone from PD shows correct levels in green (middle
row), but the yellow peaks appear only intermittently, every few
seconds, and after appearing they fall gradually down as if there were
no signal in the channel any more.
I'll try it out again on a Windows box and see if something's up with
the card itself.
Kevin
12:27 p.m.
For the record, I have the exact same problem and if I am not mistaken Tim
Blechman also does. Both Tim and myself had a problem with our PCMCIA
controllers (garbled audio) until some of the registers were changed which
enabled burst mode and some other things (different solutions for our two
controllers as they were manufactured by different companies). This fixed
the sound I/O problems and the card now works flawlessly in that respect,
but the VU meter has *exactly* the same behavior as described by Kevin
(FWIW, this does not happen in Win32 so hardware is apparently not the
issue, at least not in my case).
From briefly studying the issue: (the following applies
to the middle row of
meters, namely 1 and 2) it seems that the code for slowly
degrading the VU
meter's values through time works accurately but perhaps slower than usual
(i.e. when there is no sound, the meter should degrade at a relatively fast
pace until it reaches -infinity), but apparently refreshes of the VU meter
values are not often enough and therefore the peaks are usually well below
the actual levels and they only occasionally show up at all. It's almost as
if the refresh of the meter values is slowed down.
Also, the input signal monitoring (top row) only shows info for the first 6
or 7 inputs, the rest are dead (there should be at least 8 of the analog
ones that work), while the output levels (bottom row) generally behave in
the same fashion as the middle row but with much lower values, meaning that
most of the time they show 0 activity.
All this leads me to believe that there is a bug somewhere in the mixer that
only affects certain hardware.
Also, just for the record my PCMCIA controller is ENE1410 on an AMD64 3000+
running 32-bit Linux on a heavily modified 2.6.7 kernel.
Best wishes,
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
-----Original Message-----
From: linux-audio-user-bounces(a)music.columbia.edu [mailto:linux-audio-
user-bounces(a)music.columbia.edu] On Behalf Of Mark Knecht
Sent: Wednesday, December 15, 2004 10:34 AM
To: kevine(a)esm.rochester.edu; A list for linux audio users
Subject: Re: [linux-audio-user] HDSPmixer problem
Hi,
Family member with the HDSP 9652 using the same kernel but using
Planet Alsa support. Possibly your RPMs might have something to do
with this?
To me this sounds like a firmware revision issue. Check with other
MultiFace users as to which revision they are using.
On Wed, 15 Dec 2004 03:54:06 -0500, Kevin Ernste <kevinernste(a)gmail.com>
wrote:
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004
Hello -
I just installed a new HDSP multiface with PCI on a PlanetCCRMA/FC3
box, kernel 2.6.8.1-1.520.2vS7.ll, ALSA 1.07 (homemade rpms) and am
not seeing any output levels on HDSPmixer (bottom row) despite
actually hearing the signal I expect (sounds great).
Modules/firmware load beautifully, I can route signal with HDSPmixer
as expected, adjust levels, etc, just no visual feedback from the
outputs row either with vu levels or changing peak values.
Seems a bit strange. Default operation on my copy is that the
input/top row routes nowhere, so for input audio I have to select
where you want it to go and bring the level up before I see anything
in the bottom row. Note that if you choose a route but do not bring
the level up on the top row then the next time you look it's not
selected.
Default operation for the internal audio is vertical routing.
1-internal goes to 1-output, 2-internal goes to 2-output, etc. Default
levels are set correctly for this. This way if you choose a default
app it routes to internal 1/2 and you see output 1/2 with the same
value. Hook your output D/A there and you get sound. (Supposedly!) ;-)
Also on mixer channels that do show vu's (input and internal, top and
middle rows respectively) the yellow peak indicators appear only
randomly every 2-3 seconds or so, sort or popping around without any
clear relation to the signal peak. Something's not right here.
I see the yellow peak about 1/4" above the top of the green VU moving
as the audio does.
/sbin/lspci:
02:0d.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP (rev 0b)
cat /proc/pci:
Bus 2, device 13, function 0:
Class 0401: PCI device 10ee:3fc5 (rev 11).
IRQ 5.
Master Capable. Latency=255.
Non-prefetchable 32 bit memory at 0xec800000 [0xec80ffff].
"proc/interrupts says the card is on it's own interrupt, IRQ 5.
Is it set non-threaded?
Kevin
- Mark
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004
12:43 p.m.
On Wed, 2004-12-15 at 11:27 -0500, Ivica Ico Bukvic wrote:
For the record, I have the exact same problem and if I
am not mistaken Tim
Blechman also does.
Well, if all of you have the same problem then please file an ALSA bug
report.
https://bugtrack.alsa-project.org/alsa-bug/main_page.php
Lee
12:49 p.m.
New subject: [linux-audio-user] Re: HDSPmixer problem
UPDATE:
I just installed the latest stock Fedora kernel for kicks,
2.6.9-1.681_FC3 (using it's own ALSA modules, not sure what version)
and HDSPmixer now works. The outputs show up and peak meters fly the
way they should.
Unfortunately this kernel is probably not usable without all of
Fernando's lowlat goodies, realcap, etc...I was finally getting
excellent performance with JACK et al on
kernel-2.6.8.1-1.520.2vS7.ll...
Is there a newer 2.6.9 kernel rpm (srpm ideally) with lowlat, etc
applied out there for testing? I didn't see anything beyond
2.6.8.1-1.520.2vS7.ll in Planet SRPMS.
Kevin
On Wed, 15 Dec 2004 03:54:06 -0500, Kevin Ernste <kevinernste(a)gmail.com> wrote:
Hello -
I just installed a new HDSP multiface with PCI on a PlanetCCRMA/FC3
box, kernel 2.6.8.1-1.520.2vS7.ll, ALSA 1.07 (homemade rpms) and am
not seeing any output levels on HDSPmixer (bottom row) despite
actually hearing the signal I expect (sounds great).
Modules/firmware load beautifully, I can route signal with HDSPmixer
as expected, adjust levels, etc, just no visual feedback from the
outputs row either with vu levels or changing peak values.
Also on mixer channels that do show vu's (input and internal, top and
middle rows respectively) the yellow peak indicators appear only
randomly every 2-3 seconds or so, sort or popping around without any
clear relation to the signal peak. Something's not right here.
/sbin/lspci:
02:0d.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP (rev 0b)
cat /proc/pci:
Bus 2, device 13, function 0:
Class 0401: PCI device 10ee:3fc5 (rev 11).
IRQ 5.
Master Capable. Latency=255.
Non-prefetchable 32 bit memory at 0xec800000 [0xec80ffff].
"proc/interrupts says the card is on it's own interrupt, IRQ 5.
Kevin
1:57 p.m.
New subject: [linux-audio-user] Re: HDSPmixer problem
Here is the thread I was referring to:
http://sourceforge.net/mailarchive/message.php?msg_id=9578311
Lee
On Wed, 2004-12-15 at 11:49 -0500, Kevin Ernste wrote:
UPDATE:
I just installed the latest stock Fedora kernel for kicks,
2.6.9-1.681_FC3 (using it's own ALSA modules, not sure what version)
and HDSPmixer now works. The outputs show up and peak meters fly the
way they should.
Unfortunately this kernel is probably not usable without all of
Fernando's lowlat goodies, realcap, etc...I was finally getting
excellent performance with JACK et al on
kernel-2.6.8.1-1.520.2vS7.ll...
Is there a newer 2.6.9 kernel rpm (srpm ideally) with lowlat, etc
applied out there for testing? I didn't see anything beyond
2.6.8.1-1.520.2vS7.ll in Planet SRPMS.
Kevin
On Wed, 15 Dec 2004 03:54:06 -0500, Kevin Ernste <kevinernste(a)gmail.com> wrote:
Hello -
I just installed a new HDSP multiface with PCI on a PlanetCCRMA/FC3
box, kernel 2.6.8.1-1.520.2vS7.ll, ALSA 1.07 (homemade rpms) and am
not seeing any output levels on HDSPmixer (bottom row) despite
actually hearing the signal I expect (sounds great).
Modules/firmware load beautifully, I can route signal with HDSPmixer
as expected, adjust levels, etc, just no visual feedback from the
outputs row either with vu levels or changing peak values.
Also on mixer channels that do show vu's (input and internal, top and
middle rows respectively) the yellow peak indicators appear only
randomly every 2-3 seconds or so, sort or popping around without any
clear relation to the signal peak. Something's not right here.
/sbin/lspci:
02:0d.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP (rev 0b)
cat /proc/pci:
Bus 2, device 13, function 0:
Class 0401: PCI device 10ee:3fc5 (rev 11).
IRQ 5.
Master Capable. Latency=255.
Non-prefetchable 32 bit memory at 0xec800000 [0xec80ffff].
"proc/interrupts says the card is on it's own interrupt, IRQ 5.
Kevin
6:12 p.m.
New subject: [linux-audio-user] Re: HDSPmixer problem
On Wed, 2004-12-15 at 08:49, Kevin Ernste wrote:
UPDATE:
I just installed the latest stock Fedora kernel for kicks,
2.6.9-1.681_FC3 (using it's own ALSA modules, not sure what version)
and HDSPmixer now works. The outputs show up and peak meters fly the
way they should.
Unfortunately this kernel is probably not usable without all of
Fernando's lowlat goodies, realcap, etc...I was finally getting
excellent performance with JACK et al on
kernel-2.6.8.1-1.520.2vS7.ll...
Is there a newer 2.6.9 kernel rpm (srpm ideally) with lowlat, etc
applied out there for testing? I didn't see anything beyond
2.6.8.1-1.520.2vS7.ll in Planet SRPMS.
Coming really really soon to a Planet (CCRMA) near you... I'm currently
building a 2.6.10-rc3-mm1-v0.7.33-0 kernel (already obsolete, current is
33-4 :-), has worked fine in limited tests.
-- Fernando
On Wed, 15 Dec 2004 03:54:06 -0500, Kevin Ernste
<kevinernste(a)gmail.com> wrote:
> Hello -
>
> I just installed a new HDSP multiface with PCI on a PlanetCCRMA/FC3
> box, kernel 2.6.8.1-1.520.2vS7.ll, ALSA 1.07 (homemade rpms) and am
> not seeing any output levels on HDSPmixer (bottom row) despite
> actually hearing the signal I expect (sounds great).
>
> Modules/firmware load beautifully, I can route signal with HDSPmixer
> as expected, adjust levels, etc, just no visual feedback from the
> outputs row either with vu levels or changing peak values.
>
> Also on mixer channels that do show vu's (input and internal, top and
> middle rows respectively) the yellow peak indicators appear only
> randomly every 2-3 seconds or so, sort or popping around without any
> clear relation to the signal peak. Something's not right here.
>
> /sbin/lspci:
>
> 02:0d.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
> DSP (rev 0b)
>
> cat /proc/pci:
>
> Bus 2, device 13, function 0:
> Class 0401: PCI device 10ee:3fc5 (rev 11).
> IRQ 5.
> Master Capable. Latency=255.
> Non-prefetchable 32 bit memory at 0xec800000 [0xec80ffff].
>
> "proc/interrupts says the card is on it's own interrupt, IRQ 5.
6:36 p.m.
New subject: [linux-audio-user] Re: HDSPmixer problem
Come to think of it, perhaps it's only kernels 2.6.3-2.6.8 that have this
problem which should definitely cover myself, Kevin, and Tim. The thread
that Mark Knecht kindly provided suggests that the problem is either in the
kernel or Alsa's driver within the kernel. Someone should try the latest CVS
Alsa (me? :-) and perhaps that should shed some light as to where does the
problem stem from...
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004
7 p.m.
New subject: [linux-audio-user] Re: HDSPmixer problem
On Wed, 2004-12-15 at 14:35, Ivica Ico Bukvic wrote:
Come to think of it, perhaps it's only kernels
2.6.3-2.6.8 that have this
problem which should definitely cover myself, Kevin, and Tim. The thread
that Mark Knecht kindly provided suggests that the problem is either in the
kernel or Alsa's driver within the kernel. Someone should try the latest CVS
Alsa (me? :-) and perhaps that should shed some light as to where does the
problem stem from...
The Planet CCRMA kernel will come with extra cvs alsa drivers...
-- Fernando
8:49 p.m.
New subject: [linux-audio-user] Re: HDSPmixer problem
I use 2.6.8.1-1.520.2vS7.ll.rhfc2.ccrma & 1.0.7rc1 (pure PlanetEdge)
with the HDSP 9652 and have no problems. I think that possible this is
a Multiface and/or Digiface only problem.
On Wed, 15 Dec 2004 17:35:55 -0500, Ivica Ico Bukvic <ico(a)fuse.net> wrote:
Come to think of it, perhaps it's only kernels
2.6.3-2.6.8 that have this
problem which should definitely cover myself, Kevin, and Tim. The thread
that Mark Knecht kindly provided suggests that the problem is either in the
kernel or Alsa's driver within the kernel. Someone should try the latest CVS
Alsa (me? :-) and perhaps that should shed some light as to where does the
problem stem from...
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004
16 Dec
16 Dec
5:45 a.m.
New subject: [linux-audio-user] Re: HDSPmixer problem
Come to think of it, perhaps it's only kernels
2.6.3-2.6.8 that have
this problem which should definitely cover myself, Kevin, and Tim. The
thread that Mark Knecht kindly provided suggests that the problem is
either in the kernel or Alsa's driver within the kernel. Someone
should try the latest CVS Alsa (me? :-) and perhaps that should shed
some light as to where does the problem stem from...
i've got that problem on
2.6.9-ck3 ...
i'm not sure, where the value for the vu-meter is computed, in the card
or in the driver ... if it's in the driver, i suppose there is a wrong
area of memory that's considered as sound data ... if it's computed in
the hdsp itself (possibly, since the hardware mixer is quite powerfull)
there might be a problem with the dma on certain machines (although i
don't think that it's related to ico's and my problem with our hdsp)
cheers ... tim
--
mailto:TimBlechmann@gmx.de ICQ: 96771783
http://www.mokabar.tk
After one look at this planet any visitor from outer space
would say "I want to see the manager."
William S. Burroughs
23 Dec
23 Dec
4:27 a.m.
New subject: [linux-audio-user] HDSPconf and sync
Hi again -
First of all, many, _many_ thanks to all HDSP coders and contributers,
I've been using my multiface regularly for over a week and am
enormously impressed by the quality of tools available for this
card...and I can't imagine how ever I did without the matrix mixer ;)
Regarding the HDSP multiface and HDSPconf:
As I understand it, this card has two "speeds", single and double
corresponding to approx '48k and under' and 'over 48k' respectively.
I'm interested in 44.1K and 96K. So:
- Shouldn't the sampling rate (and "speed") be switching automatically
based on the rate of whatever file is being played (or based on
whatever rate a new JACK server requests, etc), am I missing
something? I've been setting the rate manually with HDSPconf or via my
play script with amixer (numid 11).
- Perhaps related, should I be able to set the sample clock source to
"AutoSync" (it won't stay toggled) even without external digital
connections? Is this lack of "Internal" AutoSync what's breaking
sampling rate switching/handling as mentioned above?
Happy Holidays .
Kevin
10:54 p.m.
New subject: [linux-audio-user] HDSPconf and sync
On Thu, 23 Dec 2004 03:21:05 -0500, Kevin Ernste <kevinernste(a)gmail.com> wrote:
Hi again -
First of all, many, _many_ thanks to all HDSP coders and contributers,
I've been using my multiface regularly for over a week and am
enormously impressed by the quality of tools available for this
card...and I can't imagine how ever I did without the matrix mixer ;)
Regarding the HDSP multiface and HDSPconf:
As I understand it, this card has two "speeds", single and double
corresponding to approx '48k and under' and 'over 48k' respectively.
I'm interested in 44.1K and 96K. So:
- Shouldn't the sampling rate (and "speed") be switching automatically
based on the rate of whatever file is being played (or based on
whatever rate a new JACK server requests, etc), am I missing
something? I've been setting the rate manually with HDSPconf or via my
play script with amixer (numid 11).
Kevin,
Hi.
Well, it should be.....but it doesn't, between the two speed 'ranges':
Range 1 - 44.1K/48K
Range 2) 88.2K/96K
Jack can switch between either rate in each range, but for whatever
reason it cannot switch between the two ranges themselves.
If you are running at 44.1K, you have to use hdspconf to switch to
either 88.2K or 96K. Jack could then switch from whichever you chose
to the one you want. Same for going down to 44.1K from 96K. You'll
have to do that in hdspconf also.
I know - it's a hassle.
- Perhaps related, should I be able to set the sample clock source to
"AutoSync" (it won't stay toggled) even without external digital
connections? Is this lack of "Internal" AutoSync what's breaking
sampling rate switching/handling as mentioned above?
I'm not sure about this. I use my HDSP 9652 as the system maste clock
and sync Pro Tools to it, as well as syncing my Hammerfall to it. I
use autosync on the Hammerfall ( I think - I'm not at home right now
to check) and it works fine for me.
Good luck getting things straghtened out.
- Mark
24 Dec
24 Dec
12:11 a.m.
New subject: [linux-audio-user] HDSPconf and sync
Range 1 - 44.1K/48K
Range 2) 88.2K/96K
Jack can switch between either rate in each range, but for whatever
reason it cannot switch between the two ranges themselves.
Aha, this is precicely the behaviour I was looking for _across_ the
two ranges! As you say, sampling rates change happily within each
range, just not to/from rates in the other. In any case, I'm relieved
to know that it's not my setup (things are working remarkably well
now).
I may contact the developer (if only to thank him) and inquire about
this, it seems to me that ALSA or JACK should be able to inform
HDSPconf of a rate change regardless of speed/range. It is
particularily painful at the command line where I'm jumping back and
forth between rates all the time meaning HDSPconf is always open ;)
Kevin
1:53 a.m.
New subject: [linux-audio-user] HDSPconf and sync
On Thu, 2004-12-23 at 20:11, Kevin Ernste wrote:
There was a thread long ago about this. I think the issue is that the
number of channels that the device supports change with the switch
between the two ranges of sampling rates. I don't remember why this was
a problem.
-- Fernando
Range 1 -
44.1K/48K
Range 2) 88.2K/96K
Jack can switch between either rate in each range, but for whatever
reason it cannot switch between the two ranges themselves.
Aha, this is precicely the behaviour I was looking for _across_ the
two ranges! As you say, sampling rates change happily within each
range, just not to/from rates in the other. In any case, I'm relieved
to know that it's not my setup (things are working remarkably well
now).
I may contact the developer (if only to thank him) and inquire about
this, it seems to me that ALSA or JACK should be able to inform
HDSPconf of a rate change regardless of speed/range. It is
particularily painful at the command line where I'm jumping back and
forth between rates all the time meaning HDSPconf is always open ;)
2:22 a.m.
New subject: [linux-audio-user] HDSPconf and sync
Thanks, Fernando. I'll scan the devel lists for this discussion.
I would assume that this change of # of channels (visible with
HDSPmixer) would only mandate that the range/speed not be changed
while in operation. This might even mean shutting down JACK or other
clients at times, etc. Totally understandable.
However it should be able to change rates when a file at a new rate is
played or when JACK requests a new rate. I can force it to work now
just by adding an alias for all apps which scans the soundfilefile
header and sends the appropriate "amixer numid=11" switch before
playing or opening the file. I assume ALSA can do something similar
on its own (?).
I'm sure I oversimplifying ;)
Kevin
On 23 Dec 2004 21:53:34 -0800, Fernando Lopez-Lezcano
<nando(a)ccrma.stanford.edu> wrote:
On Thu, 2004-12-23 at 20:11, Kevin Ernste wrote:
There was a thread long ago about this. I think the issue is that the
number of channels that the device supports change with the switch
between the two ranges of sampling rates. I don't remember why this was
a problem.
-- Fernando
Range 1 -
44.1K/48K
Range 2) 88.2K/96K
Jack can switch between either rate in each range, but for whatever
reason it cannot switch between the two ranges themselves.
Aha, this is precicely the behaviour I was looking for _across_ the
two ranges! As you say, sampling rates change happily within each
range, just not to/from rates in the other. In any case, I'm relieved
to know that it's not my setup (things are working remarkably well
now).
I may contact the developer (if only to thank him) and inquire about
this, it seems to me that ALSA or JACK should be able to inform
HDSPconf of a rate change regardless of speed/range. It is
particularily painful at the command line where I'm jumping back and
forth between rates all the time meaning HDSPconf is always open ;)
3:15 p.m.
New subject: [linux-audio-user] HDSPconf and sync
On 23 Dec 2004 21:53:34 -0800, Fernando Lopez-Lezcano
<nando(a)ccrma.stanford.edu> wrote:
On Thu, 2004-12-23 at 20:11, Kevin Ernste wrote:
There was a thread long ago about this. I think the issue is that the
number of channels that the device supports change with the switch
between the two ranges of sampling rates. I don't remember why this was
a problem.
-- Fernando
Hi,
Yes - there have been two or three threads about this, I think. The
number of 'user visible' channels does change between the two ranges.
RME 'binds' two channels running at 44.1K to make an 88.2K ADAT
channel. The ADAT interface itself does not run at 88.2K. It's just a
logical combination of the data on both channels to make it look like
the card is runnign 88.2K. (Or 2x48K to make 96K)
Unfortunately this is not a globally supported mode of operation
for ADAT devices. None of the Pro Tools hardware I have supports this.
It does work fine between RME cards though.
- Mark
Range 1 -
44.1K/48K
Range 2) 88.2K/96K
Jack can switch between either rate in each range, but for whatever
reason it cannot switch between the two ranges themselves.
Aha, this is precicely the behaviour I was looking for _across_ the
two ranges! As you say, sampling rates change happily within each
range, just not to/from rates in the other. In any case, I'm relieved
to know that it's not my setup (things are working remarkably well
now).
I may contact the developer (if only to thank him) and inquire about
this, it seems to me that ALSA or JACK should be able to inform
HDSPconf of a rate change regardless of speed/range. It is
particularily painful at the command line where I'm jumping back and
forth between rates all the time meaning HDSPconf is always open ;)
3:29 p.m.
New subject: [linux-audio-user] HDSPconf and sync
On Fri, 2004-12-24 at 12:15 -0700, Mark Knecht wrote:
On 23 Dec 2004 21:53:34 -0800, Fernando Lopez-Lezcano
<nando(a)ccrma.stanford.edu> wrote:
I also seem to recall there was some kind of an issue where you cannot
distinguish an incoming 44.1 stream for an 88.2 (or 48 from 96) stream
with half the number of channels, or something. This was either
discussed on the list, or maybe in the comments in the driver source.
Lee
On Thu, 2004-12-23 at 20:11, Kevin Ernste wrote:
There was a thread long ago about this. I think the issue is that the
number of channels that the device supports change with the switch
between the two ranges of sampling rates. I don't remember why this was
a problem.
-- Fernando
Hi,
Yes - there have been two or three threads about this, I think. The
number of 'user visible' channels does change between the two ranges.
RME 'binds' two channels running at 44.1K to make an 88.2K ADAT
channel. The ADAT interface itself does not run at 88.2K. It's just a
logical combination of the data on both channels to make it look like
the card is runnign 88.2K. (Or 2x48K to make 96K)
Unfortunately this is not a globally supported mode of operation
for ADAT devices. None of the Pro Tools hardware I have supports this.
It does work fine between RME cards though. Range 1 -
44.1K/48K
Range 2) 88.2K/96K
Jack can switch between either rate in each range, but for whatever
reason it cannot switch between the two ranges themselves.
Aha, this is precicely the behaviour I was looking for _across_ the
two ranges! As you say, sampling rates change happily within each
range, just not to/from rates in the other. In any case, I'm relieved
to know that it's not my setup (things are working remarkably well
now).
I may contact the developer (if only to thank him) and inquire about
this, it seems to me that ALSA or JACK should be able to inform
HDSPconf of a rate change regardless of speed/range. It is
particularily painful at the command line where I'm jumping back and
forth between rates all the time meaning HDSPconf is always open ;)
9:43 p.m.
New subject: [linux-audio-user] HDSPconf and sync
On Fri, 24 Dec 2004 14:29:46 -0500, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Fri, 2004-12-24 at 12:15 -0700, Mark Knecht wrote:
Maybe we cannot distinguish it but RME drivers can. I can set one to
auto sync and then on the other card tell it to be the master and
switch between 44K and 96K. The autosync end indicates the correct
frequencies.
I think it's certainly easier to know in advance which way you want to
run though.
- Mark
On 23 Dec 2004 21:53:34 -0800, Fernando
Lopez-Lezcano
<nando(a)ccrma.stanford.edu> wrote:
I also seem to recall there was some kind of an issue where you cannot
distinguish an incoming 44.1 stream for an 88.2 (or 48 from 96) stream
with half the number of channels, or something. This was either
discussed on the list, or maybe in the comments in the driver source.
Lee On Thu, 2004-12-23 at 20:11, Kevin Ernste wrote:
Hi,
Yes - there have been two or three threads about this, I think. The
number of 'user visible' channels does change between the two ranges.
RME 'binds' two channels running at 44.1K to make an 88.2K ADAT
channel. The ADAT interface itself does not run at 88.2K. It's just a
logical combination of the data on both channels to make it look like
the card is runnign 88.2K. (Or 2x48K to make 96K)
Unfortunately this is not a globally supported mode of operation
for ADAT devices. None of the Pro Tools hardware I have supports this.
It does work fine between RME cards though. > Range 1 - 44.1K/48K
> Range 2) 88.2K/96K
>
> Jack can switch between either rate in each range, but for whatever
> reason it cannot switch between the two ranges themselves.
Aha, this is precicely the behaviour I was looking for _across_ the
two ranges! As you say, sampling rates change happily within each
range, just not to/from rates in the other. In any case, I'm relieved
to know that it's not my setup (things are working remarkably well
now).
I may contact the developer (if only to thank him) and inquire about
this, it seems to me that ALSA or JACK should be able to inform
HDSPconf of a rate change regardless of speed/range. It is
particularily painful at the command line where I'm jumping back and
forth between rates all the time meaning HDSPconf is always open ;)
There was a thread long ago about this. I think the issue is that the
number of channels that the device supports change with the switch
between the two ranges of sampling rates. I don't remember why this was
a problem.
-- Fernando
15 Dec
15 Dec
6:36 p.m.
New subject: [linux-audio-user] Re: HDSPmixer problem
Am Mittwoch, 15. Dezember 2004 23:12 schrieb Fernando Lopez-Lezcano:
On Wed, 2004-12-15 at 08:49, Kevin Ernste wrote:
wrote:
UPDATE:
I just installed the latest stock Fedora kernel for kicks,
2.6.9-1.681_FC3 (using it's own ALSA modules, not sure what version)
and HDSPmixer now works. The outputs show up and peak meters fly the
way they should.
Unfortunately this kernel is probably not usable without all of
Fernando's lowlat goodies, realcap, etc...I was finally getting
excellent performance with JACK et al on
kernel-2.6.8.1-1.520.2vS7.ll...
Is there a newer 2.6.9 kernel rpm (srpm ideally) with lowlat, etc
applied out there for testing? I didn't see anything beyond
2.6.8.1-1.520.2vS7.ll in Planet SRPMS.
Coming really really soon to a Planet (CCRMA) near you... I'm currently
building a 2.6.10-rc3-mm1-v0.7.33-0 kernel (already obsolete, current is
33-4 :-), has worked fine in limited tests.
-- Fernando
> On Wed, 15 Dec 2004 03:54:06 -0500, Kevin Ernste <kevinernste(a)gmail.com>
> > Hello -
> >
> > I just installed a new HDSP multiface with PCI on a PlanetCCRMA/FC3
> > box, kernel 2.6.8.1-1.520.2vS7.ll, ALSA 1.07 (homemade rpms) and am
> > not seeing any output levels on HDSPmixer (bottom row) despite
> > actually hearing the signal I expect (sounds great).
> >
> > Modules/firmware load beautifully, I can route signal with HDSPmixer
> > as expected, adjust levels, etc, just no visual feedback from the
> > outputs row either with vu levels or changing peak values.
> >
> > Also on mixer channels that do show vu's (input and internal, top and
> > middle rows respectively) the yellow peak indicators appear only
> > randomly every 2-3 seconds or so, sort or popping around without any
> > clear relation to the signal peak. Something's not right here.
> >
> > /sbin/lspci:
> >
> > 02:0d.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
> > DSP (rev 0b)
> >
> > cat /proc/pci:
> >
> > Bus 2, device 13, function 0:
> > Class 0401: PCI device 10ee:3fc5 (rev 11).
> > IRQ 5.
> > Master Capable. Latency=255.
> > Non-prefetchable 32 bit memory at 0xec800000 [0xec80ffff].
> >
> > "proc/interrupts says the card is on it's own interrupt, IRQ 5.
I had a similar problem with SUSE 9.2 and the 2.6.8 Kernel. Idon't know if it
is a 2.6.8 problem or a problem of ALSA 1.07 or a combination of both.
Now I work with SUSE 9.1 and a customized 2.6.5 Kernel and the HDSP Mixer work
fine. I hope we will find a solution soon.
Ciao
Martin
7318
days inactive
7327
days old
linux-audio-user@lists.linuxaudio.org
23 comments
7 participants
participants (7)
-
Fernando Lopez-Lezcano -
Ivica Ico Bukvic -
Kevin Ernste -
Lee Revell -
Mark Knecht -
Martin Wohlleben -
Tim Blechmann