From: Lee Revell <rlrevell@joe-job.com>
To: James Courtier-Dutton <James@superbug.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>,
alsa-devel <alsa-devel@lists.sourceforge.net>
Subject: Re: [PATCH] emu10k1 multichannel support
Date: Wed, 26 Jan 2005 13:05:19 -0500 [thread overview]
Message-ID: <1106762719.2935.77.camel@krustophenia.net> (raw)
In-Reply-To: <41F2F481.2000304@superbug.co.uk>
On Sun, 2005-01-23 at 00:49 +0000, James Courtier-Dutton wrote:
> I am currently doing work on the P16V chip that is on the Audigy 2 sound
> cards. It will be able to capture and playback 4 stereo channels at the
> same time, at anything from 44.1 khz up to 192khz. It can also pass
> samples to and from the EMU10K2 DSP, but it transfers them in blocks of
> 8 mono channels. e.g. DSP fxchannel 0-7 or 8-15 or 16-23 etc.
> So, I think it would be better if the multichannel patch you are doing
> uses those groupings of channels for multichannel play/capture.
OK. I have read your patch, it's really a marvel of reverse
engineering. So far I have not tackled the problem of how to present
the multichannel capture controls to the user in a reasonable way. For
now my patch hardcodes the EFX voices mask control to capture 16 of the
upper outputs (FXBUS2 and A_FXBUS2). These correspond to the high 16
bits of FXWC on SBLive and the low 16 bits of A_FXWC2 on Audigy. I also
plan to support channel counts other than 16 for playback.
Meanwhile I have updated the definitions of the I/O GPRs to reflect the
current knowledge of the hardware. This makes implementing FXBUS and
P16V capture easier. Actually you could test the P16V -> DSP signal
path now, just change A_FXBUS to A_P16VIN in this line from my patch:
/* EFX capture - capture the first 16 FX buses */
for (z = 0; z < 16; z++) {
A_OP(icode, &ptr, iACC3, A_FXBUS2(z), A_C_00000000, A_C_00000000, A_FXBUS(z));
}
and you should be able to capture the 48Khz-resampled P16V streams with hw:0,2.
Hmm, that gives me an idea, there are 16 more A_FXBUS2 recording inputs,
we could just connect the P16V outputs like so:
/* P16V capture - capture the 16 P16V inputs */
for (z = 16; z < 32; z++) {
A_OP(icode, &ptr, iACC3, A_FXBUS2(z), A_C_00000000, A_C_00000000, A_P16VIN(z - 16));
}
Then you could have a mixer control that sets the low 16 bits of A_FXWC2
to capture the first 16 FX buses***, or the high 16 bits to capture the
P16V inputs, or both. While we are at it we should let them set the low
16 bits of A_FXWC1 to capture the physical outs or the high 16 to
capture ???. On SBLive they can set the low 16 FXWC bits to capture
their physical outs or the high 16 to capture the FX buses***.
It gets slightly more complicated if you want to let them capture groups
of 8 because you have to decide which 8. Also the groups of 16 channels
seem to form logical units. Anyway capturing P16V via the DSP is handy
for testing but it's really not going to be a common use of the device.
People who want to use the DSP will run at 48Khz and people who want
44.1, 96 or 192khz will just use the P16V. The only application I can
remotely think of is a video game with 24/96 content that wants to use
the DSP for 3D audio/EAX type stuff, which isn't even implemented on
Linux.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v006.patch
Audigy:
#define A_FXBUS(x) (0x00 + (x)) /* x = 0x00 - 0x3f FX buses */
#define A_EXTIN(x) (0x40 + (x)) /* x = 0x00 - 0x0f physical ins */
#define A_P16VIN(x) (0x50 + (x)) /* x = 0x00 - 0x0f p16v ins (A2 only) "EMU32 inputs" */
#define A_EXTOUT(x) (0x60 + (x)) /* x = 0x00 - 0x1f physical outs -> A_FXWC1 0x79-7f unknown */
#define A_FXBUS2(x) (0x80 + (x)) /* x = 0x00 - 0x1f extra outs used for EFX capture -> A_FXWC2 */
#define A_EMU32OUTH(x) (0xa0 + (x)) /* x = 0x00 - 0x0f "EMU32_OUT_10 - _1F" - ??? */
#define A_EMU32OUTL(x) (0xb0 + (x)) /* x = 0x00 - 0x0f "EMU32_OUT_1 - _F" - ??? */
#define A_GPR(x) (A_FXGPREGBASE + (x))
SBLive:
/* GPRs */
#define FXBUS(x) (0x00 + (x)) /* x = 0x00 - 0x0f */
#define EXTIN(x) (0x10 + (x)) /* x = 0x00 - 0x0f */
#define EXTOUT(x) (0x20 + (x)) /* x = 0x00 - 0x0f physical outs -> FXWC low 16 bits */
#define FXBUS2(x) (0x30 + (x)) /* x = 0x00 - 0x0f copies of fx buses for capture -> FXWC high 16 bits */
/* NB: 0x31 and 0x32 are shared with Center/LFE on SB live 5.1 */
Lee
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
next prev parent reply other threads:[~2005-01-26 18:05 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-18 23:31 [PATCH] emu10k1 multichannel support Lee Revell
2005-01-19 14:38 ` William
2005-01-19 16:10 ` Lee Revell
2005-01-19 16:59 ` Lee Revell
2005-01-19 17:49 ` William
2005-01-19 18:20 ` William
2005-01-19 18:24 ` Lee Revell
2005-01-19 16:48 ` Takashi Iwai
2005-01-19 19:10 ` Lee Revell
2005-01-21 21:45 ` Lee Revell
2005-01-23 0:49 ` James Courtier-Dutton
2005-01-26 18:05 ` Lee Revell [this message]
2005-01-23 20:05 ` Lee Revell
2005-01-29 3:54 ` Lee Revell
2005-01-31 16:09 ` Bug in " Mikael Magnusson
2005-02-10 22:17 ` Lee Revell
2005-02-10 23:26 ` Mikael Magnusson
2005-02-11 1:55 ` Lee Revell
2005-02-11 18:41 ` Lee Revell
2005-02-11 20:32 ` Mikael Magnusson
2005-02-10 23:33 ` Shayne O'Connor
2005-02-11 0:59 ` Lee Revell
2005-02-11 1:35 ` Shayne O'Connor
2005-02-11 1:33 ` Lee Revell
2005-02-11 2:31 ` Shayne O'Connor
2005-02-11 3:55 ` Lee Revell
2005-02-11 9:54 ` Takashi Iwai
2005-01-19 19:51 ` [Alsa-user] [PATCH] " Alexander Samad
2005-01-19 21:11 ` Lee Revell
2005-01-19 21:25 ` Alexander Samad
2005-01-19 22:16 ` Alexander Samad
2005-01-19 22:19 ` Alexander Samad
2005-01-19 22:54 ` [Alsa-user] " Lee Revell
2005-01-21 21:41 ` Lee Revell
2005-01-22 0:49 ` James Courtier-Dutton
2005-01-23 20:31 ` [Alsa-devel] " Alexander Samad
2005-01-25 17:09 ` Brian L Scipioni
2005-01-25 18:43 ` [Alsa-user] " Lee Revell
[not found] ` <1106743059.30763.21.camel@radium.gaugetheory.org>
[not found] ` <1106756424.2935.1.camel@krustophenia.net>
[not found] ` <s5hu0p3nimh.wl@alsa2.suse.de>
2005-01-27 18:41 ` [Alsa-user] emu10k1 alsamixer items Lee Revell
2005-01-28 15:33 ` Takashi Iwai
[not found] ` <1108148365.4267.22.camel@radium.gaugetheory.org>
2005-02-11 19:41 ` [PATCH] emu10k1 multichannel support Lee Revell
2005-02-11 20:11 ` Brian L Scipioni
2005-02-11 20:14 ` [Alsa-user] " Lee Revell
2005-02-15 14:20 ` Brian L Scipioni
[not found] ` <1108148630.4267.28.camel@radium.gaugetheory.org>
2005-02-11 19:44 ` emu10k1 MIDI record Lee Revell
2005-02-11 20:06 ` Brian L Scipioni
2005-02-11 20:12 ` [Alsa-user] " Lee Revell
2005-02-12 15:34 ` Brian L Scipioni
2005-02-12 23:51 ` [Alsa-user] " Lee Revell
2005-02-15 14:44 ` Brian L Scipioni
2005-01-25 21:33 ` [Alsa-user] [PATCH] emu10k1 multichannel support 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=1106762719.2935.77.camel@krustophenia.net \
--to=rlrevell@joe-job.com \
--cc=James@superbug.co.uk \
--cc=alsa-devel@lists.sourceforge.net \
--cc=tiwai@suse.de \
/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.