All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Courtier-Dutton <James@superbug.demon.co.uk>
To: Lee Revell <rlrevell@joe-job.com>
Cc: alsa-devel@lists.sourceforge.net, pzad@pobox.sk, joachim.falk@gmx.de
Subject: Re: [PATCH] fix for ac97->front speaker routing (was Re:	Some Patches for emu10k1)
Date: Sun, 27 Jun 2004 00:57:18 +0100	[thread overview]
Message-ID: <40DE0D5E.7000204@superbug.demon.co.uk> (raw)
In-Reply-To: <1088287234.24275.113.camel@mindpipe>

Lee Revell wrote:
> On Tue, 2004-06-15 at 18:18, Joachim Falk wrote:
> 
>>|>But some FX buses seam to be connected to outputs even if there is no
>>|>code in the dsp. Is that hardcoded in hardware or configurable and if
>>|>yes where ?
>>|
>>|
>>| This is maybe hardware feature or ld10k1 bug. If you connect FX bus
>>| 0,1 to AC97 PCM output I think it will stop to do this.
>>This seams to be a hardware feature of the EMU10K1 I think because if
>>you clear the dsp code than FX bus channels 0,1 and 8,9 will be
>>forwarded to Output channels 0,1 and 8,9. This I can say for sure.
>>The others (2-7 and 10-15) I can not be sure because I have no speakers
>>on these channels or they are not connected to output on my card. But I
>>assume that to be the case too. As soon as you start driving an output
>>within your DSP code the forwarding seams to vanish. I think this can
>>not be a alsa driver feature because you can verify that the DSP really
>>is empty by catting /proc/asound/Live/fx8010_acode. So the alsa driver
>>has no possibility to magically insert some of its one forwardings if
>>none are programmed by the user.
> 
> 
> I believe I have figured this out.  The following lines are taken from
> 8010.h in the kX Project SDK.  This file is basically the same as
> emu10k1.h in the ALSA driver, with some interesting additions.  The
> following lines are *not* present in the ALSA driver:
> 

Have you actually tested changing those bits? Does it actually stop the 
AC97 output reaching the Front speakers?

I have been working on the AudigyLS driver that uses what I will call a 
P17 chip.

The Audigy 2 card has a P16V chip.
The P17 chip is quite similar to the P16V chip.

I have found that the general layout of the chips is that all inputs go 
into the P17 chip. The P17 chip then has some registers that adjust the 
volume of different routes.
For example. On the AudigyLS, all the input from the MIC or LINE IN goes 
via the PLAYBACK parts(not the CAPTURE) of the AC97 chip and into the 
Philips 24bit ADC.
MIC -> AC97 -> Analog link -> Philips 24bit ADC -> P17 -> P17 register 
volume control -> Front speakers.

The P17 then has a register that sets the volume for the ADC direct to 
Front speakers route. Most people will want the MIC to be recorded, and 
not be sent directly to the speakers, so I have set this route to muted.

I expect the Audigy 2 is much the same.
1) MIC -> AC97 -> Analog link -> Philips ADC -> P16V -> P16V register(a) 
volume control -> Front speakers.
2) CPU -> DMA access for EMU10k2 -> I2S digital link -> P16V -> P16V 
register(b) volume control -> Front speakers.
3) CPU -> DMA access for P16V -> P16V register(c) volume control -> 
Front speakers.

There are actually some special lines of code in the emu10k1_main.c:
/* Hacks for Alice3 to work independent of haP16V driver */
...

Those are setting up the "I2S digital link" for the Audigy2.

P16V register(a),(b) and (c) are probably different registers.

The default volume levels are all set at 0dB, so as the "hacks for 
Alice3" don't include register(a), one will by default get feedback from 
the MIC direct to the front speakers.

I have almost got enough information on the P16V now, in order to make 
use of it.
I have:
1) DMA control registers (They are the same for the P16V and P17).
2) Switching between 48khz and 96khz.
I still need:
1) Which bits to set to get the interrupts working.
2) Setting 24bit output mode.

Work so far on the P17
I still need:
1) Switching between 48khz and 96khz.
2) Setting 24bit output mode.
I already have:
1) DMA control registers.
2) Interrupts working.
3) Volume controls
4) Digital/Analog outputs.

Cheers
James


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

  reply	other threads:[~2004-06-26 23:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-08  8:07 Some Patches for emu10k1 Peter Zubaj
2004-06-15 22:18 ` Joachim Falk
2004-06-26 22:00   ` [PATCH] fix for ac97->front speaker routing (was Re: Some Patches for emu10k1) Lee Revell
2004-06-26 23:57     ` James Courtier-Dutton [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-06-28  6:55 Peter Zubaj
2004-06-28 19:50 ` Lee Revell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40DE0D5E.7000204@superbug.demon.co.uk \
    --to=james@superbug.demon.co.uk \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=joachim.falk@gmx.de \
    --cc=pzad@pobox.sk \
    --cc=rlrevell@joe-job.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.