RE: [Alsa-devel] hdsp multiface pci.
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Roger > Williams > Sent: Wednesday, January 22, 2003 10:31 AM > To: Paul Davis > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Alsa-devel] hdsp multiface pci. > > > >>>>> Paul Davis <[EMAIL PROTECTED]> writes: > > >> This would explain why snd_hdsp works (i.e. you can playback and > >> record through the default I/O), although amixer doesn't do > >> anything: the driver doesn't have to set up any default > >> connections, because those are part of the FPGA reset state... > > > actually, the driver does have to set up default connections, > > which are zero gain for every possible routing... > > Yes, I understand that that's what the driver is _supposed_ to do. > That's how it works on my HDSP PCI and Cardbus systems. But isn't it > true that the current driver doesn't actually set up any of those > zero-gain connections for the HDSP 9652? > > This is the only point that I was trying to make to Mark -- the > default unity-gain connections (i.e. playback -> H/W output) that he > has been using are FPGA configuration defaults, not explicitly set up > by the driver. > Yes, and I think I understood that this was probably what was happening as our conversation progressed. When I made that statement it was a bit earlier on, if I remember correctly, and I was explaining my 'vision' of what I thought was going on. That should not be confused with the trusth! ;-) It makes perfect sense that the RME card itself has some default connections. Thanks, Mark --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
>Yes, I understand that that's what the driver is _supposed_ to do. >That's how it works on my HDSP PCI and Cardbus systems. But isn't it >true that the current driver doesn't actually set up any of those >zero-gain connections for the HDSP 9652? well, it attempts to, but its writing to the wrong registers. >This is the only point that I was trying to make to Mark -- the >default unity-gain connections (i.e. playback -> H/W output) that he >has been using are FPGA configuration defaults, not explicitly set up >by the driver. correct. i actually don't have any idea what those defaults are. --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
> Paul Davis <[EMAIL PROTECTED]> writes: >> This would explain why snd_hdsp works (i.e. you can playback and >> record through the default I/O), although amixer doesn't do >> anything: the driver doesn't have to set up any default >> connections, because those are part of the FPGA reset state... > actually, the driver does have to set up default connections, > which are zero gain for every possible routing... Yes, I understand that that's what the driver is _supposed_ to do. That's how it works on my HDSP PCI and Cardbus systems. But isn't it true that the current driver doesn't actually set up any of those zero-gain connections for the HDSP 9652? This is the only point that I was trying to make to Mark -- the default unity-gain connections (i.e. playback -> H/W output) that he has been using are FPGA configuration defaults, not explicitly set up by the driver. -- Roger Williams <[EMAIL PROTECTED]> Qux Tool & Die, Middleborough, Massachusetts // Omne tulit punctum qui misquit utile dulci // --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
>This would explain why snd_hdsp works (i.e. you can playback and >record through the default I/O), although amixer doesn't do anything: >the driver doesn't have to set up any default connections, because >those are part of the FPGA reset state. I would be surprised if actually, the driver does have to set up default connections, which are zero gain for every possible routing unless the line_outs_monitor option is set to a non-zero value. in that case, all h/w input streams and all s/w playback streams are routed at unity gain to the two line out channels, with stereo assignment following an odd->left, even->right mapping. as i've told mark independently, the hdsp-9652 has different register assignments for the mixer, and until recently i did not have that information from rme. the hdsp-9652 effectively has no mixer at this time on linux. --p --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
> Thinking about it this morning though, it seems to me that > possibly the default routing of audio doesn't go through the mixer > at all? I'm quite sure that all output connections (from either the inputs or the playback channels) are made through the HDSP mixer. However, it's quite possible that the HDSP FPGA sets up default unity-gain connections between the playback channels and their corresponding outputs (and mutes all of the connections between hardware inputs and outputs) when it's initialised. This would explain why snd_hdsp works (i.e. you can playback and record through the default I/O), although amixer doesn't do anything: the driver doesn't have to set up any default connections, because those are part of the FPGA reset state. I would be surprised if snd_hdsp could set up connections, but amixer couldn't. I provided that sample script which tells amixer to disconnect everything so that you could see if _any_ amixer matrix mixer controls have an effect on your card (because if they did, it's possible that the 9652 simply has a different matrix mapping). -- Roger Williams <[EMAIL PROTECTED]> Qux Tool & Die, Middleborough, Massachusetts // Omne tulit punctum qui misquit utile dulci // --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
Roger,
I'm in the office right now, so I'll pop home at noon PST and happily try
out things.
Yesterday the only thing were you seemed to differ with me on my description
of things was how Alsa_pcm:playback signals got to the physical outputs. I said
they were hooked up automatically, by the driver. I think you felt otherwise.
Possibly that is part of this problem I'm having?
My test setup was pretty simple. I started alsaplayer and qjackconnect so
that I could see how things were hooked up. Standard default hookup takes
alsaplayer audio and sends it to playback_1/2. This goes out through ADAT-1,
channels 1 & 2, and to a PowerPlay Pro headphone amp. My headphones are plugged
in there.
With a CD in the drive I can hear sound through my headphones.
At this point I believe that Alsa_pcm:playback_1/2 are hooked to physical
outputs 1/2 since I get sound.
I then run (from my sleepy memory)
amixer cset numid=5 26,0,300
amixer cset numid=5 27,1,300
to reduce volume, but it doesn't. No values in the '300' position seemed to do
anything.
For clarification, what I thought I was doing with the above command was
taking playback_1/2 (26,27) and routing them through the mixer to physical
I/O's 0&1. If the numbering is wrong, that set of commands could certainly be
incorrect. (Or I'm still just not understanding things and plain mixed up.)
Thinking about it this morning though, it seems to me that possibly the
default routing of audio doesn't go through the mixer at all? If this is the
case, then maybe I need to break whatever the default conection is before I can
hear the effects of the mixer? Is this the purpose of your script below?
Let me know where you think I'm going wrong.
Thanks!
Mark
> Hi, Mark --
>
> > When I tried some amixer commands I was disappointed to find that
> > they do nothing at all on my machine. No command I tried seems to
> > control volume to my headphones or speakers at all.
>
> Could you briefly explain your test setup and what amixer commands
> you've been generating? I'm surprised that the ALSA driver seems to
> work, yet amixer doesn't.
>
> Are you setting the "line_outs_monitor" parameter in /etc/modules.conf?
> (You shouldn't.)
>
> When you try to zero all of the mixer routes, does it have any effect?
> Perhaps the channels are mapped differently than we think. This
> script will try to zero all 1352 channels for you:
>
> #!/bin/bash
>
> ADAT1="0 1 2 3 4 5 6 7"
> ADAT2="8 9 10 11 12 13 14 15"
> ADAT3="16 17 18 19 20 21 22 23"
> SPDIF="24 25"
>
> function disconnect () {
> for output in "$@"; do
> input=0
> while [ $input -le 25 ]; do
> echo -n "."
> amixer cset numid=5 $input,$output,0 > /dev/null
> input=$((input+1))
> done
> done
> echo
> }
>
> echo -n "Disconnecting ADAT1 outputs"
> disconnect $ADAT1
> echo -n "Disconnecting ADAT2 outputs"
> disconnect $ADAT2
> echo -n "Disconnecting ADAT3 outputs"
> disconnect $ADAT3
> echo -n "Disconnecting SPDIF output"
> disconnect $SPDIF
>
> --
> Roger Williams <[EMAIL PROTECTED]>
> Qux Tool & Die, Middleborough, Massachusetts
> // Omne tulit punctum qui misquit utile dulci //
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
Roger, I'm just using an AI-3 for now. Nothing fancy. Paul Davis told me maybe 2 months ago that RME had not provided him with the programming information for the mixer, but when I purchased the card I didn't realize the disconnect was quite this fundamental. Live an learn. Maybe one day I'll be able to use this feature. I would think that Thomas's Total Mix clone won't help me either? Mark > > Mark Knecht <[EMAIL PROTECTED]> writes: > > >When I tried some amixer commands I was disappointed to find that > > they do nothing at all on my machine. No command I tried seems to > > control volume to my headphones or speakers at all. > > >I guess the HDSP 9652 is not supported at this time. Makes me feel > > like I bought the wrong product. > > Bummer. It seems odd that the ALSA driver (apparently) works, but > amixer doesn't. Out of curiousity, what sort of outboard converters > are you using for your analogue outputs? > > -- > Roger Williams <[EMAIL PROTECTED]> > Qux Tool & Die, Middleborough, Massachusetts > // Omne tulit punctum qui misquit utile dulci // > > > --- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > ___ > Alsa-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/alsa-devel --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
> Mark Knecht <[EMAIL PROTECTED]> writes: >When I tried some amixer commands I was disappointed to find that > they do nothing at all on my machine. No command I tried seems to > control volume to my headphones or speakers at all. >I guess the HDSP 9652 is not supported at this time. Makes me feel > like I bought the wrong product. Bummer. It seems odd that the ALSA driver (apparently) works, but amixer doesn't. Out of curiousity, what sort of outboard converters are you using for your analogue outputs? -- Roger Williams <[EMAIL PROTECTED]> Qux Tool & Die, Middleborough, Massachusetts // Omne tulit punctum qui misquit utile dulci // --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
> Marcus Andersson <[EMAIL PROTECTED]> writes: > The panners and the output faders are mapped to the matrix mixer > controls by the TotalMix software. They have no correspondence in > hardware. Thanks for the confirmation, Marcus. That's what I suspected. -- Roger Williams <[EMAIL PROTECTED]> Qux Tool & Die, Middleborough, Massachusetts // Omne tulit punctum qui misquit utile dulci // --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
Roger, First, thanks for taking time to follow this through with me. This has been helpful and I do at least feel like I'm starting to understand what the software is tying to do. When I tried some amixer commands I was disappointed to find that they do nothing at all on my machine. No command I tried seems to control volume to my headphones or speakers at all. I guess the HDSP 9652 is not supported at this time. Makes me feel like I bought the wrong product. Anyway, I will continue to study and understand this stuff and hope that one day some of these features actually work. Thanks for your help! Cheers, Mark On Mon, 2003-01-20 at 06:25, Roger Williams wrote: > > Mark Knecht <[EMAIL PROTECTED]> writes: > > > I can think of my HDSP mixer as a device with 52 inputs and 26 > > outputs. > > In the case of the 9652, you don't have headphone outputs, so you > don't have the Digiface's 27th and 28th outputs. > > > 1) 26 mixer inputs come from the HDSP's physical inputs > > - numbered 0-25 in the mixer > > - called Alsa_pcm:capture_1 - 26 in Jack > > Yup. > > > 2) 26 mixer inputs come from the Alsa:playback group > > - numbered 26-51 in the mixer > > - called Alsa_pcm:playback_1 - 26 in Jack > > Yup. > > > 1) 26 mixer outputs come from the mixer > > - numbered 0-25 out of the mixer > > Yup. > > > By default, the HDSP driver then takes the Alsa_pcm:playback group > > and hooks them to (more or less) matching output destinations: > > Perhaps, but I'm not sure about that. I always explicitly set up the > HDSP mixer routes. I just removed all of my ALSA modules, removed the > HDSP Cardbus card, power-cycled the Multiface, and reinstalled > everything; and I had to issue an "amixer cset numid=5 26,0,32768" > command to connect alsa_pcm:playback_1 to Multiface output 1. > > > so that if I connect capture_1 to playback_1 then whatever comes > > in on the ADAT-1, channel 0 input will get sent back out on > > ADAT-1, channel 1 output. > > You don't connect capture_1 to playback_1, because playback_1 is a > signal coming from ALSA, going into the HDSP mixer. But you _can_ > connect the signal arriving on the ADAT1:1 input (which _also_ drives > ALSA's capture_1 input) to the ADAT1:1 output with an "amixer cset > numid=5 0,0,32768" command. (But playback_1 isn't routed to the > ADAT1:1 output except by coincidence or a default setting -- playback_1 > doesn't have anything to do with your ADAT1:1 input -> ADAT1:1 output > connection.) > > > amixer cset numid=5 0,0,32768 > > amixer cset numid=5 1,1,32768 > > ... > > amixer cset numid=5 25,25,32768 > > > which would route each physical input to each physical output, 1 > > for 1, at a volume of unity gain. (As per Marcus's notes again.) > > Yup. > > > What is not at all clear yet is whether a single input can go to > > multiple outs with different gains. For instance, if I execute: > > > amixer cset numid=5 0,0,1 > > amixer cset numid=5 0,1,3 > > Sure, that works just fine. I'll run a combined setup like this: > > Monitor submix > == > amixer cset numid=5 0,26,2 > amixer cset numid=5 1,27,2 > amixer cset numid=5 2,26,15000 > amixer cset numid=5 3,27,15000 > amixer cset numid=5 4,26,1 > amixer cset numid=5 5,27,1 > > DAT safety recording > == > amixer cset numid=5 0,24,16384 > amixer cset numid=5 1,25,16384 > amixer cset numid=5 2,24,12288 > amixer cset numid=5 3,25,12288 > amixer cset numid=5 4,24,8192 > amixer cset numid=5 5,25,8192 > > The changes I make in the first group (headphones submix) don't have > any effect on the signal being recorded by the DAT, which is set up in > the second group. > > > I am attempting to take physical input 0 and sending it to both > > the left and right outputs, but at different volumes. Is this > > legal? > > Sure. Consider RME's description of TotalMix, which is "nothing more" > than a software interface (OK, I'm a hardware guy) to the HDSP mixer: > > - setting up delay-free submixes (headphone mixes) > - unlimited routing of inputs and outputs (free utilisation, patchbay function) > - distributing signals to several outputs at a time > - simultaneous playback of different programs over only one stereo channel > - mixing of the input signal to the playback signal (complete ASIO Direct >Monitoring) > - integration of external devices (effects etc). in real-time > - mixdown of three ADAT inputs to one (realizing two additional inputs) > > RME calls the HDSP mixer in the Multiface a "720 channel" mixer, and > the one in the Digiface "1456 channels". (The 9652 would be 1352 > channels, because it doesn't have the headphone outputs.) For the > Multiface, that's [18 hardware input channels + 18 playback channels] > x 20 hardware output channels. (There are only 18 playback channe
Re: [Alsa-devel] hdsp multiface pci.
Roger Williams wrote: > > They provide a fairly clear picture of what the hardware can do; but > it doesn't map exactly to the amixer behaviour I see. Specifically, I > haven't figured out how to adjust the output faders (between each > output and its dedicated buss) or the input pans (each input is shown > as driving a pair of busses through a fader and a pan, rather than > through two independent faders). The panners and the output faders are mapped to the matrix mixer controls by the TotalMix software. They have no correspondence in hardware. Marcus --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
Mark, have you looked at the block diagrams of the HDSP mixer in the HDSP manuals, or read the technical overview of the HDSP mixer hardware at http://www.rme-audio.de/english/techinfo/hdsp_tmhard.htm ? They provide a fairly clear picture of what the hardware can do; but it doesn't map exactly to the amixer behaviour I see. Specifically, I haven't figured out how to adjust the output faders (between each output and its dedicated buss) or the input pans (each input is shown as driving a pair of busses through a fader and a pan, rather than through two independent faders). Perhaps Thomas knows all the details of this? -- Roger Williams <[EMAIL PROTECTED]> Qux Tool & Die, Middleborough, Massachusetts // Omne tulit punctum qui misquit utile dulci // --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
> Mark Knecht <[EMAIL PROTECTED]> writes: > I can think of my HDSP mixer as a device with 52 inputs and 26 > outputs. In the case of the 9652, you don't have headphone outputs, so you don't have the Digiface's 27th and 28th outputs. > 1) 26 mixer inputs come from the HDSP's physical inputs > - numbered 0-25 in the mixer > - called Alsa_pcm:capture_1 - 26 in Jack Yup. > 2) 26 mixer inputs come from the Alsa:playback group > - numbered 26-51 in the mixer > - called Alsa_pcm:playback_1 - 26 in Jack Yup. > 1) 26 mixer outputs come from the mixer > - numbered 0-25 out of the mixer Yup. > By default, the HDSP driver then takes the Alsa_pcm:playback group > and hooks them to (more or less) matching output destinations: Perhaps, but I'm not sure about that. I always explicitly set up the HDSP mixer routes. I just removed all of my ALSA modules, removed the HDSP Cardbus card, power-cycled the Multiface, and reinstalled everything; and I had to issue an "amixer cset numid=5 26,0,32768" command to connect alsa_pcm:playback_1 to Multiface output 1. > so that if I connect capture_1 to playback_1 then whatever comes > in on the ADAT-1, channel 0 input will get sent back out on > ADAT-1, channel 1 output. You don't connect capture_1 to playback_1, because playback_1 is a signal coming from ALSA, going into the HDSP mixer. But you _can_ connect the signal arriving on the ADAT1:1 input (which _also_ drives ALSA's capture_1 input) to the ADAT1:1 output with an "amixer cset numid=5 0,0,32768" command. (But playback_1 isn't routed to the ADAT1:1 output except by coincidence or a default setting -- playback_1 doesn't have anything to do with your ADAT1:1 input -> ADAT1:1 output connection.) > amixer cset numid=5 0,0,32768 > amixer cset numid=5 1,1,32768 > ... > amixer cset numid=5 25,25,32768 > which would route each physical input to each physical output, 1 > for 1, at a volume of unity gain. (As per Marcus's notes again.) Yup. > What is not at all clear yet is whether a single input can go to > multiple outs with different gains. For instance, if I execute: > amixer cset numid=5 0,0,1 > amixer cset numid=5 0,1,3 Sure, that works just fine. I'll run a combined setup like this: Monitor submix == amixer cset numid=5 0,26,2 amixer cset numid=5 1,27,2 amixer cset numid=5 2,26,15000 amixer cset numid=5 3,27,15000 amixer cset numid=5 4,26,1 amixer cset numid=5 5,27,1 DAT safety recording == amixer cset numid=5 0,24,16384 amixer cset numid=5 1,25,16384 amixer cset numid=5 2,24,12288 amixer cset numid=5 3,25,12288 amixer cset numid=5 4,24,8192 amixer cset numid=5 5,25,8192 The changes I make in the first group (headphones submix) don't have any effect on the signal being recorded by the DAT, which is set up in the second group. > I am attempting to take physical input 0 and sending it to both > the left and right outputs, but at different volumes. Is this > legal? Sure. Consider RME's description of TotalMix, which is "nothing more" than a software interface (OK, I'm a hardware guy) to the HDSP mixer: - setting up delay-free submixes (headphone mixes) - unlimited routing of inputs and outputs (free utilisation, patchbay function) - distributing signals to several outputs at a time - simultaneous playback of different programs over only one stereo channel - mixing of the input signal to the playback signal (complete ASIO Direct Monitoring) - integration of external devices (effects etc). in real-time - mixdown of three ADAT inputs to one (realizing two additional inputs) RME calls the HDSP mixer in the Multiface a "720 channel" mixer, and the one in the Digiface "1456 channels". (The 9652 would be 1352 channels, because it doesn't have the headphone outputs.) For the Multiface, that's [18 hardware input channels + 18 playback channels] x 20 hardware output channels. (There are only 18 playback channels because playback_8-15 aren't used in the Multiface.) > In my case, I use Alsa_pcm:playback_1/2 for my main speakers, and > playback_3/4 for my headphones. The problem I've been having is that I > didn't know how to set the volume on my speakers with no mixer. Using > this information, I could execute: > amixer cset numid=5 26,0,3000 > amixer cset numid=5 27,1,3000 > and now my playback_1/2 should come out of my speakers, but at > considerably reduced volumes. Yup. -- Roger Williams <[EMAIL PROTECTED]> Qux Tool & Die, Middleborough, Massachusetts // Omne tulit punctum qui misquit utile dulci // --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourc
Re: [Alsa-devel] hdsp multiface pci.
Roger, I think the light is just starting to turn on, or at least I can only hope... ;-) See if you can help me improve the following description. I can think of my HDSP mixer as a device with 52 inputs and 26 outputs. The inputs look like: 1) 26 mixer inputs come from the HDSP's physical inputs - numbered 0-25 in the mixer - called Alsa_pcm:capture_1 - 26 in Jack 2) 26 mixer inputs come from the Alsa:playback group - numbered 26-51 in the mixer - called Alsa_pcm:playback_1 - 26 in Jack The outputs look like: 1) 26 mixer outputs come from the mixer - numbered 0-25 out of the mixer By default, the HDSP driver then takes the Alsa_pcm:playback group and hooks them to (more or less) matching output destinations: Alsa_pcm:playback_1 -> HDSP Output 0 Alsa_pcm:playback_2 -> HDSP Output 1 ... Alsa_pcm:playback_26 -> HDSP Output 25 so that if I connect capture_1 to playback_1 then whatever comes in on the ADAT-1, channel 0 input will get sent back out on ADAT-1, channel 1 output. To test this idea, and using your headphone mix example, I should be able to create a hardware monitoring setup by routing physical inputs directory to physical outputs using something like this: amixer cset numid=5 0,0,32768 amixer cset numid=5 1,1,32768 ... amixer cset numid=5 25,25,32768 which would route each physical input to each physical output, 1 for 1, at a volume of unity gain. (As per Marcus's notes again.) What is not at all clear yet is whether a single input can go to multiple outs with different gains. For instance, if I execute: amixer cset numid=5 0,0,1 amixer cset numid=5 0,1,3 I am attempting to take physical input 0 and sending it to both the left and right outputs, but at different volumes. Is this legal? I'm not sure. In my case, I use Alsa_pcm:playback_1/2 for my main speakers, and playback_3/4 for my headphones. The problem I've been having is that I didn't know how to set the volume on my speakers with no mixer. Using this information, I could execute: amixer cset numid=5 26,0,3000 amixer cset numid=5 27,1,3000 and now my playback_1/2 should come out of my speakers, but at considerably reduced volumes. I'm going to stop and get feedback, as this is almost making sense. In the meantime, I might as well try the commands above and see if my speaker volume is under control. Thanks very much for your help! Cheers, Mark On Mon, 2003-01-20 at 02:14, Roger Williams wrote: > > Mark Knecht <[EMAIL PROTECTED]> writes: > > > This is very, very helpful. > > What will be "very, very helpful" will be Thomas's TotalMix clone! :) > > > ... it appears that the MultiFace has a slightly different > > numbering system for your analog channels, starting with 0-7 > > instead of what I think I have which starts with 1-8. > > My "amixer controls" dump looks the same as yours. I don't know what > "index=1" means, but it doesn't appear to mean that our cset indexing > begins at 1. I've got to assume that Paul or Thomas already know > everything there is to know about the HDSP mixer, and I hate to > explore known territory, but when you don't have a map... > > > When you say 'appear to be numbered like this', how did you determine > > this? Was it documented somewhere? Or did you have to test yourself? > > Well, it matches Marcus Andersson's notes on the ALSA HDSP page: > > input_source: 0-7 (analog), 16-23 (adat), 24-25 (spdif), 26-51 (playback) > output_source: 0-7 (analog), 16-23 (adat) 24-25 (spdif), 26-27 (line out) > > I found "output_source" confusing, but it makes sense if I rename it > "destination". > > > The MultiFace has 18 inputs ... so I would have expected you to list: > > Some of the numbering is discontinuous (because the Multiface doesn't > have the Digiface's ADAT2 range of channels), so the full Multiface > I/O list is: > > Inputs to HDSP Mixer > > Multiface analogue inputs 1-8 = amixer source channels 0-7 > Multiface ADAT inputs 1-8 = amixer source channels 16-23 > Multiface SPDIF input = amixer source channels 24-25 > alsa_pcm:playback_1-26 = amixer source channels 26-51 > > Outputs from HDSP Mixer > > Multiface analogue outputs 1-8 = amixer destination channels 0-7 > Multiface ADAT outputs 1-8 = amixer destination channels 16-23 > Multiface SPDIF output = amixer destination channels 24-25 > Multiface line (headphone) output = amixer destination channels 26-27 > > Mapping between Multiface inputs and alsa_pcm:capture channels > > Multiface analogue inputs 1-8 = capture_1-8 > Multiface ADAT inputs 1-8 = capture_9-16 > Multiface SPDIF input = capture_17-18 > > > In my case I am guessing that my physical I/O numbering will be > > > H
Re: [Alsa-devel] hdsp multiface pci.
> Mark Knecht <[EMAIL PROTECTED]> writes: > This is very, very helpful. What will be "very, very helpful" will be Thomas's TotalMix clone! :) > ... it appears that the MultiFace has a slightly different > numbering system for your analog channels, starting with 0-7 > instead of what I think I have which starts with 1-8. My "amixer controls" dump looks the same as yours. I don't know what "index=1" means, but it doesn't appear to mean that our cset indexing begins at 1. I've got to assume that Paul or Thomas already know everything there is to know about the HDSP mixer, and I hate to explore known territory, but when you don't have a map... > When you say 'appear to be numbered like this', how did you determine > this? Was it documented somewhere? Or did you have to test yourself? Well, it matches Marcus Andersson's notes on the ALSA HDSP page: input_source: 0-7 (analog), 16-23 (adat), 24-25 (spdif), 26-51 (playback) output_source: 0-7 (analog), 16-23 (adat) 24-25 (spdif), 26-27 (line out) I found "output_source" confusing, but it makes sense if I rename it "destination". > The MultiFace has 18 inputs ... so I would have expected you to list: Some of the numbering is discontinuous (because the Multiface doesn't have the Digiface's ADAT2 range of channels), so the full Multiface I/O list is: Inputs to HDSP Mixer Multiface analogue inputs 1-8 = amixer source channels 0-7 Multiface ADAT inputs 1-8 = amixer source channels 16-23 Multiface SPDIF input = amixer source channels 24-25 alsa_pcm:playback_1-26 = amixer source channels 26-51 Outputs from HDSP Mixer Multiface analogue outputs 1-8 = amixer destination channels 0-7 Multiface ADAT outputs 1-8 = amixer destination channels 16-23 Multiface SPDIF output = amixer destination channels 24-25 Multiface line (headphone) output = amixer destination channels 26-27 Mapping between Multiface inputs and alsa_pcm:capture channels Multiface analogue inputs 1-8 = capture_1-8 Multiface ADAT inputs 1-8 = capture_9-16 Multiface SPDIF input = capture_17-18 > In my case I am guessing that my physical I/O numbering will be > HDSP 9652 ADAT-1 inputs 1-8= amixer source channels 1-8 > HDSP 9652 ADAT-2 inputs 9-16 = amixer source channels 8-16 > HDSP 9652 ADAT-3 inputs 17-24 = amixer source channels 17-24 > HDSP 9652 s/pdif inputs 25-26 = amixer source channels 25-26 I'm pretty sure that the amixer ranges will be 0-7, 8-15, 16-23, and 24-25, respectively. I believe that matches the Digiface (which also has its analogue headphone output on 26-27, as I recall). -- Roger Williams <[EMAIL PROTECTED]> Qux Tool & Die, Middleborough, Massachusetts // Omne tulit punctum qui misquit utile dulci // --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
Roger, This is very, very helpful. Thanks for sharing this info. I am trying to do similar things with the HDSP 9652, which is similar but a bit different, I'd like to address a couple more things. (Darn...Tennessee just scored!) :-((( 7-7 I just want to clearly understand the physical I/O numbering right now. Once I've got that I'll ask you a couple of questions about the mixer if I may. OK, it appears that the MultiFace has a slightly different numbering system for your analog channels, starting with 0-7 instead of what I think I have which starts with 1-8. Is this correct? If I look at the HDSP amixer info, I seem to start with an index of 1, not 0. Am I looking at the right stuff? (I've done some sorting to make this more readable to me. I have this initial section with 9 controls, and then 26 sections that are identical to the second area I show below, indexing from 1-26. I presume that your first one would start with index=0? [mark@Godzilla mark]$ amixer controls numid=1,iface=PCM,name='IEC958 Playback Default' numid=3,iface=MIXER,name='IEC958 Playback Con Mask' numid=4,iface=MIXER,name='IEC958 Playback Pro Mask' numid=5,iface=PCM,name='Mixer' numid=6,iface=PCM,name='IEC958 Input Connector' numid=7,iface=PCM,name='IEC958 Output also on ADAT1' numid=8,iface=PCM,name='Preferred Sync Source' numid=9,iface=PCM,name='Passthru' numid=10,iface=PCM,name='Line Out' numid=11,iface=MIXER,name='Chn',index=1 numid=12,iface=PCM,name='Input Peak',index=1 numid=13,iface=PCM,name='Output Peak',index=1 numid=14,iface=PCM,name='Playback Peak',index=1 numid=15,iface=PCM,name='Playback RMS',index=1 numid=16,iface=PCM,name='Input RMS',index=1 On Sun, 2003-01-19 at 22:24, Roger Williams wrote: > > Mark Knecht <[EMAIL PROTECTED]> writes: > > Second, where do the inputs numbered 26-33 come from. > > As far as the Multiface's analogue I/O goes, channels appear to be > numbered like this: When you say 'appear to be numbered like this', how did you determine this? Was it documented somewhere? Or did you have to test yourself? > > Multiface inputs 1-8 = amixer source channels 0-7 > Multiface outputs 1-8 = amixer destination channels 0-7 > Multiface line (headphone) outputs = amixer destination channels 26-27 > alsa_pcm:playback_1-8 = amixer source channels 26-33 > OK, here's where you throw me. Let me list out what I thought I knew about the MultiFace, and then correct me where I'm wrong please. The MultiFace has 18 inputs - 8 analog, 8 ADAT, 2 s/pdif, and 20 outputs (including the Headphone outs if they are really separate from everything else. They may not be...) so I would have expected you to list: (Yea!!! Raiders score! 14-7) MultiFace analog inputs 1-8 = amixer source channels 0-7 MultiFace ADAT inputs 9-16 = amixer source channels W-X (8-16?) MultiFace s/pdif inputs 17-18 = amixer source channels Y-Z (17-18?) Basically, to use the 18 inputs, they all must have unique numbers. Correct? MultiFace analog outputs 1-8= amixer dest. channels 0-7 MultiFace ADAT outputs 9-16 = amixer dest. channels W-X (8-16?) MultiFace s/pdif outputs 17-18 = amixer dest. channels Y-Z (17-18?) MultiFace Line outputs 1-2 = amixer dest. channels 26-27 Maybe all of the features of the MultiFace not actually supported in the current driver, so you didn't list them, or maybe you just didn't use them, so you didn't write them down? In my case I am guessing that my physical I/O numbering will be as follows: HDSP 9652 ADAT-1 inputs 1-8 = amixer source channels 1-8 HDSP 9652 ADAT-2 inputs 9-16= amixer source channels 8-16 HDSP 9652 ADAT-3 inputs 17-24 = amixer source channels 17-24 HDSP 9652 s/pdif inputs 25-26 = amixer source channels 25-26 and similar numbering for the outputs. Do you think this is right? Any other thoughts or comments? Thanks, Mark --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
Is there a single amixer control to reset all of the HDSP mixer
registers? I recall that there's some mechanism for resetting the
HDSP (other than re-installing the module), but I can't find it now.
For now, I use scripts like this to configure the mixer paths:
#!/bin/bash
# mute all Multiface analogue I/O connections
inputs="0 1 2 3 4 5 6 7 26 27 28 29 30 31 32 33"
analogue_outputs="0 1 2 3 4 5 6 7"
headphone_outputs="26 27"
function disconnect () {
for output in "$@"; do
for input in $inputs; do
echo -n "."
amixer cset numid=5 $input,$output,0 > /dev/null
done
done
echo
}
echo -n "Disconnecting analogue outputs"
disconnect $analogue_outputs
echo -n "Disconnecting headphone outputs"
disconnect $headphone_outputs
--
Roger Williams <[EMAIL PROTECTED]>
Qux Tool & Die, Middleborough, Massachusetts
// Omne tulit punctum qui misquit utile dulci //
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
> Mark Knecht <[EMAIL PROTECTED]> writes: >> amixer cset numid=5 26,26,16384 >> amixer cset numid=5 28,26,16384 >> amixer cset numid=5 30,26,16384 >> amixer cset numid=5 32,26,16384 >> amixer cset numid=5 27,27,16384 >> amixer cset numid=5 29,27,16384 >> amixer cset numid=5 31,27,16384 >> amixer cset numid=5 33,27,16384 > ... is the use of 26 and 27 on the output part of the command > telling the hardware to route whatever it is that you're mixing to > the line out connectors on your box? Yes. (Not outputs 1 & 2, as I erroneously stated.) > Second, where do the inputs numbered 26-33 come from. As far as the Multiface's analogue I/O goes, channels appear to be numbered like this: Multiface inputs 1-8 = amixer source channels 0-7 Multiface outputs 1-8 = amixer destination channels 0-7 Multiface line (headphone) outputs = amixer destination channels 26-27 alsa_pcm:playback_1-8 = amixer source channels 26-33 So amixer cset numid=5 0,26,16384" routes the signal from input 0 to the left headphone channel. And "amixer cset numid=5 0,0,16384" routes the signal from input 0 to output 0. And for i in 0 2 4 6; do amixer cset numid=5 $i,0,16384; done for i in 1 3 5 7; do amixer cset numid=5 $i,1,16384; done will route inputs 1+3+5+7 to output 1, and inputs 2+4+6+8 to output 2. On playback "amixer cset numid=5 26,0,16384" routes the playback_1 source to Multiface output 1, and for i in 26 28 30 32; do amixer cset numid=5 $i,0,16384; done for i in 27 29 31 33; do amixer cset numid=5 $i,1,16384; done routes playback_1+3+5+7 to output 1 and playback_2+4+6+8 to output 2. > I presume that your use of 16384 is to reduce volume so that after > summing 4 channels you do not create output clipping if all the inputs > hit maximum volume at the same time? Yes. This is just a submix for headphone monitoring, so I route it to outputs 26 and 27. This is a monitor submix I use when recording with ecasound. If I were using Ardour, I'd set up a monitor submix in Ardour itself, and route outputs 1 and 2 to the headphone output with amixer cset numid=5 26,26,65535 amixer cset numid=5 27,27,65535 > If you wanted to route input 0 directly to an output, could > you use a command like: > amixer cset numid=5 0,26,16384 > amixer cset numid=5 1,27,16384 This routes hardware inputs 1 and 2 to the headphone outputs. -- Roger Williams <[EMAIL PROTECTED]> Qux Tool & Die, Middleborough, Massachusetts // Omne tulit punctum qui misquit utile dulci // --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
On Sun, 2003-01-19 at 17:00, Roger Williams wrote: > > Patrick Shirkey <[EMAIL PROTECTED]> writes: > > > Can we route multiple software outputs to the same hardware output? > > Yes. For instance, when recording 8 tracks, I'll generate a monitor > mix (for JACK's outputs) to outputs 1 & 2 like this: > > amixer cset numid=5 26,26,16384 > amixer cset numid=5 28,26,16384 > amixer cset numid=5 30,26,16384 > amixer cset numid=5 32,26,16384 > amixer cset numid=5 27,27,16384 > amixer cset numid=5 29,27,16384 > amixer cset numid=5 31,27,16384 > amixer cset numid=5 33,27,16384 > > -- Roger, OK, I just don't get it yet. This is from the Alsa page on the HDSP cards: * Since the Multiface only have 18 i/o channels, the channel mapping in the matrix mixer is different from the Digiface when operating at 48kHz or lower. [Ed. This is a routing table] input_source: 0-7 (analog), 16-23 (adat), 24-25 (spdif), 26-51 (playback) output_source: 0-7 (analog), 16-23 (adat) 24-25 (spdif), 26-27 (line out) * In your example above, is the use of 26 and 27 on the output part of the command telling the hardware to route whatever it is that you're mixing to the line out connectors on your box? Second, where do the inputs numbered 26-33 come from. I can't figure this part out. Are they outputs from the HDSP hardware mixer? Or do they mean from physical inputs? (somehow renumbered) This is the part I don't get right now. I presume that your use of 16384 is to reduce volume so that after summing 4 channels you do not create output clipping if all the inputs hit maximum volume at the same time? QUESTION - If you wanted to route input 0 directly to an output, could you use a command like: amixer cset numid=5 0,26,16384 amixer cset numid=5 1,27,16384 I think my HDSP 9652 will have different numbering since I have a different number of I/O's on the card, but I want to understand your example since it seems like a good one. Thanks, Mark --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
On Sun, 2003-01-19 at 09:23, Mark Knecht wrote: > Thomas, >I have possibly more than a passing interest in this subject as I use > the HDSP 9652 card that Patrick mentioned and find this whole amixer > language completely unfathomable. > >In your quote above, could you outline what each parameter stands > for? > > "numid=5 26,26,16384" > > numid=5 - Is this a physical connection? A mixer input or output? An > abstract number just used to keep track of things? > numid=5 is a way to identify the control we want to work with, i.e. the matrix mixer. Controls are defined on a per soundcard basis to address specific driver needs uncovered by the "simple controls" you can access through alsamixer. > 26,26 - clearly Patrick and I were thinking that these two numbers > related to specific hardware inputs and outputs, but apparently not. > Yes they are. To understand them you should refer to the table Patrick gave (quoting the HDSP alsa page, link follows). > 16384 - a mixer volume? > Yes, you should read Marcus Andersson's comments on this here: http://www.alsa-project.org/alsa-doc/doc-php/template.php3?company=RME&card=Hammerfall+DSP&chip=FPGA&module=hdsp (at the end of the page) Thomas --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
On Sun, 2003-01-19 at 17:33, Patrick Shirkey wrote: > I have added it as an editors note on the hdsp page. Thanks. > so it's default is a fifo? > > i.e software output 26 -> analog output 1 > software output 27 -> analog output 2 > Strangely said, but yes. > Therefore can I do this? > > numid=5 26,0,16384 > numid=5 27,1,16384 > numid=5 28,2,16384 > numid=5 29,3,16384 > numid=5 30,4,16384 > numid=5 31,5,16384 > numid=5 32,6,16384 > numid=5 33,7,16384 > > Or is that the default setting (except with no volume). > Rather than bothering to use amixer, you'd better use alsamixer to control those. These are the standard volume controls. (Internally the volume controls use the matrix mixer) If you want to hear sound through analog outputs 1-2 using software outputs 1-2, you can either use amixer (e.g. amixer cset numid=5 26,0,16384) or alsamixer. > So we have to tell the control called numid=5 to route > the output from software 1 to line out before we can hear it through > line out? > Yes. The control called numid=5 is the interface to the matrix mixer. > Can we route multiple software outputs to the same hardware output? > > eg. numid=5 26,26,16384 > numid=5 27,27,16384 > numid=5 28,26,16384 > numid=5 29,27,16384 > numid=5 30,26,16384 > numid=5 31,27,16384 > numid=5 32,26,16384 > numid=5 33,27,16384 > Yes we can :) > Or is that what the .asoundrc is for? > I don't know if you can do it with the .asoundrc file (I would rather doubt it). Anyway the clear benefit of doing it with amixer is that it is hardware mixing, thus consuming no system resources. >From your latest post: > In essence the hdsp can run 18 software streams at the same time as > processing upto 18 hardware input streams? > Yes. In fact the hdsp system can run up to 26 of them (digiface). > Do I need to set the volume for the analog inputs? Or will I be able > to > capture from them without setting anything in amixer? > You'll be able to capture without setting anything in amixer Thomas --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
Patrick Shirkey wrote: Thomas Charbonnel wrote: You have to understand that software outputs are not directly related to physical outputs. On simpler hardware, software and physical outputs can be considered the same. On the hdsp system, thanks to the internal matrix mixer, software outputs are totally abstracted from physical ones. On the multiface you have 18 software outputs, each of wich can be independently routed to any of the 18 physical outputs. For convenience, the hdsp linux driver's default behaviour is to have a 1:1 routing policy: each software output is by default routed to to corresponding hardware output. In essence the hdsp can run 18 software streams at the same time as processing upto 18 hardware input streams? Do I need to set the volume for the analog inputs? Or will I be able to capture from them without setting anything in amixer? -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
> Patrick Shirkey <[EMAIL PROTECTED]> writes: > Can we route multiple software outputs to the same hardware output? Yes. For instance, when recording 8 tracks, I'll generate a monitor mix (for JACK's outputs) to outputs 1 & 2 like this: amixer cset numid=5 26,26,16384 amixer cset numid=5 28,26,16384 amixer cset numid=5 30,26,16384 amixer cset numid=5 32,26,16384 amixer cset numid=5 27,27,16384 amixer cset numid=5 29,27,16384 amixer cset numid=5 31,27,16384 amixer cset numid=5 33,27,16384 -- Roger Williams <[EMAIL PROTECTED]> Qux Tool & Die, Middleborough, Massachusetts // Omne tulit punctum qui misquit utile dulci // --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
Thomas Charbonnel wrote: You have to understand that software outputs are not directly related to physical outputs. On simpler hardware, software and physical outputs can be considered the same. On the hdsp system, thanks to the internal matrix mixer, software outputs are totally abstracted from physical ones. On the multiface you have 18 software outputs, each of wich can be independently routed to any of the 18 physical outputs. For convenience, the hdsp linux driver's default behaviour is to have a 1:1 routing policy: each software output is by default routed to to corresponding hardware output. So the "numid=5 26,26,16384" line says: connect software output 1 (called "playback" in the above table) to line out left, as the syntax of the call is input_source,output_source,value. Great explanation. I have added it as an editors note on the hdsp page. so it's default is a fifo? i.e software output 26 -> analog output 1 software output 27 -> analog output 2 Therefore can I do this? numid=5 26,0,16384 numid=5 27,1,16384 numid=5 28,2,16384 numid=5 29,3,16384 numid=5 30,4,16384 numid=5 31,5,16384 numid=5 32,6,16384 numid=5 33,7,16384 Or is that the default setting (except with no volume). Here it looks like you're mixing up the amixer numid parameter number with the hdsp internal channel numbers. Numid 5 is the actual alsa matrix mixer control. Numid 10 is the global line out switch. Numid 26 and 27 are read only, and correspond to the internal peak and rms calculation the card does to provide a 0% CPU metering solution (to be used in the forthcoming HDSPMixer totalmix clone !...) I hope this makes things clearer. Getting there. So we have to tell the control called numid=5 to route the output from software 1 to line out before we can hear it through line out? Can we route multiple software outputs to the same hardware output? eg. numid=5 26,26,16384 numid=5 27,27,16384 numid=5 28,26,16384 numid=5 29,27,16384 numid=5 30,26,16384 numid=5 31,27,16384 numid=5 32,26,16384 numid=5 33,27,16384 Or is that what the .asoundrc is for? -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
On Sun, 2003-01-19 at 16:07, Thomas Charbonnel wrote: > > So the "numid=5 26,26,16384" line says: > connect software output 1 (called "playback" in the above table) to line > out left, as the syntax of the call is input_source,output_source,value. > Thomas, I have possibly more than a passing interest in this subject as I use the HDSP 9652 card that Patrick mentioned and find this whole amixer language completely unfathomable. In your quote above, could you outline what each parameter stands for? "numid=5 26,26,16384" numid=5 - Is this a physical connection? A mixer input or output? An abstract number just used to keep track of things? 26,26 - clearly Patrick and I were thinking that these two numbers related to specific hardware inputs and outputs, but apparently not. 16384 - a mixer volume? Thanks in advance for helping. Cheers, Mark --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
On Sun, 2003-01-19 at 16:29, Patrick Shirkey wrote: > Sorry I'm not fully grasping this. Why are 26 and 27 directly related to > alsa_pcm:playback_1 and _2? > > I thought from reading the notes on the hdsp page that pcm1 and pcm2 > would be numbers 0 and 1 not 26 and 27. > > eg. > == > Since the Multiface only have 18 i/o channels, the channel mapping in > the matrix mixer is different from the Digiface when operating at 48kHz > or lower. > > input_source: 0-7 (analog), 16-23 (adat), 24-25 (spdif), 26-51 (playback) > output_source: 0-7 (analog), 16-23 (adat) 24-25 (spdif), 26-27 (line out) > == > > See how it says 0-7 (analog)? > > I haven't found an explanation for the following in the docs describing > how to use the amixer app so could you please clarify this for me? > > What is this line saying? > > numid=5 26,26,16384 > > something like: > > connect 26 to 5 with a volume of 16384 > > You have to understand that software outputs are not directly related to physical outputs. On simpler hardware, software and physical outputs can be considered the same. On the hdsp system, thanks to the internal matrix mixer, software outputs are totally abstracted from physical ones. On the multiface you have 18 software outputs, each of wich can be independently routed to any of the 18 physical outputs. For convenience, the hdsp linux driver's default behaviour is to have a 1:1 routing policy: each software output is by default routed to to corresponding hardware output. So the "numid=5 26,26,16384" line says: connect software output 1 (called "playback" in the above table) to line out left, as the syntax of the call is input_source,output_source,value. > > > >>or > >>numid=5 10,10,16384 <<<--- 10 appears to be line out id > >> > > > > > > What makes you say so ? > > > > These are the id's in question: > > numid=5,iface=PCM,name='Mixer' >; type=INTEGER,access=rw---,values=3,min=0,max=65536,step=1 >: values=16384,0,0 > > numid=10,iface=PCM,name='Line Out' >; type=BOOLEAN,access=rw---,values=1 >: values=on > > numid=26,iface=PCM,name='Playback Peak',index=3 >; type=INTEGER,access=r,values=2,min=0,max=0,step=0 >: values=0,0 > > numid=27,iface=PCM,name='Playback RMS',index=3 >; type=INTEGER64,access=r,values=1,min=0,max=0,step=0 >: values=0 > > Here it looks like you're mixing up the amixer numid parameter number with the hdsp internal channel numbers. Numid 5 is the actual alsa matrix mixer control. Numid 10 is the global line out switch. Numid 26 and 27 are read only, and correspond to the internal peak and rms calculation the card does to provide a 0% CPU metering solution (to be used in the forthcoming HDSPMixer totalmix clone !...) I hope this makes things clearer. Thomas --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
Another question. What are each of these? IEC958 Playback Con Mask IEC958 Playback Pro Mask Chn IEC958 Input Connector IEC958 Output also on ADAT1 IEC958 Playback Default Input Peak Input RMS Line Out Mixer Output Peak Passthru Playback Peak Playback RMS Preferred Sync Source = Some are self explanatory but I will add it to the notes if someone will go through and explain each one. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
Thomas Charbonnel wrote: On Sun, 2003-01-19 at 13:08, Patrick Shirkey wrote: Using latest cvs, I have been trying to get this device working for my friend. We have had some success but it is unreliable. We could get sound out of the lineout port after using this command amixer -D hw:0 cset numid=5 0,0,16384 This is supposed to route the signal received on analog input 1 to analog output 1. numid=5,iface=PCM,name='Mixer' ; type=INTEGER,access=rw---,values=3,min=0,max=65536,step=1 : values=16384,0,0 Using numid=5 26,26,16384 numid=5 27,27,16384 The above should indeed be the correct way to route software playback channels 1-2 to the line outs (jack's alsa_pcm:playback_1 and _2, for example). Sorry I'm not fully grasping this. Why are 26 and 27 directly related to alsa_pcm:playback_1 and _2? I thought from reading the notes on the hdsp page that pcm1 and pcm2 would be numbers 0 and 1 not 26 and 27. eg. == Since the Multiface only have 18 i/o channels, the channel mapping in the matrix mixer is different from the Digiface when operating at 48kHz or lower. input_source: 0-7 (analog), 16-23 (adat), 24-25 (spdif), 26-51 (playback) output_source: 0-7 (analog), 16-23 (adat) 24-25 (spdif), 26-27 (line out) == See how it says 0-7 (analog)? I haven't found an explanation for the following in the docs describing how to use the amixer app so could you please clarify this for me? What is this line saying? numid=5 26,26,16384 something like: connect 26 to 5 with a volume of 16384 or numid=5 10,10,16384 <<<--- 10 appears to be line out id What makes you say so ? These are the id's in question: numid=5,iface=PCM,name='Mixer' ; type=INTEGER,access=rw---,values=3,min=0,max=65536,step=1 : values=16384,0,0 numid=10,iface=PCM,name='Line Out' ; type=BOOLEAN,access=rw---,values=1 : values=on numid=26,iface=PCM,name='Playback Peak',index=3 ; type=INTEGER,access=r,values=2,min=0,max=0,step=0 : values=0,0 numid=27,iface=PCM,name='Playback RMS',index=3 ; type=INTEGER64,access=r,values=1,min=0,max=0,step=0 : values=0 -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
On Sun, 2003-01-19 at 13:08, Patrick Shirkey wrote: > Using latest cvs, I have been trying to get this device working for my > friend. We have had some success but it is unreliable. > > We could get sound out of the lineout port after using this command > > amixer -D hw:0 cset numid=5 0,0,16384 > This is supposed to route the signal received on analog input 1 to analog output 1. > numid=5,iface=PCM,name='Mixer' >; type=INTEGER,access=rw---,values=3,min=0,max=65536,step=1 >: values=16384,0,0 > > Using > > numid=5 26,26,16384 > numid=5 27,27,16384 The above should indeed be the correct way to route software playback channels 1-2 to the line outs (jack's alsa_pcm:playback_1 and _2, for example). > or > numid=5 10,10,16384 <<<--- 10 appears to be line out id > What makes you say so ? > seem to do nothing. > > Sometimes after trying to use aplay and usually when trying alsaplayer > amixer resets the volume to 0. > > Is this buggy behaviour? > Maybe there is a bug in the matrix mixer. Yesterday, while working in a complex setup, I couldn't manage to route analog inputs 3-4 to analog outputs 3-4, it just didn't work. I had those inputs routed to the line outs, and could hear the signal, but nothing came out of ouputs 3-4. I had to route inputs 3-4 to outputs 5-6 to get it working. As we were rehearsing, I had no time to further investigate. One of the problem preventing proper understanding of the situation is that you actually can't read from the mixer control, as cget doesn't take a parameter. I know Paul is not fully satisfied with the way the matrix mixer is handled right now. Maybe it could be changed so that reading the mixer state is possible. I am currently writing a totalmix clone, and reading the mixer state could really prove usefull. Imagine you're working with a complex mixer setup and accidentally close the mixer app. If you relaunch the app, it won't be able to read the mixer state back, and will have to fall back on a preset. Your mixing work will be lost. Other examples of the need of mixer state readout include synchronization between different apps using the mixer. I plan to implement a ladspa plugin to control the matrix mixer, so that you could automate hardware mixing in ardour, for example. The plugin and the standalone mixer app should stay synced. Thomas --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
