openvortex-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openvortex-dev] Src Cleanup


From: Jeff Muizelaar
Subject: Re: [Openvortex-dev] Src Cleanup
Date: Sun, 18 May 2003 22:53:02 -0400 (EDT)


On Sun, 18 May 2003, Manuel Jander wrote:

> Hi everyone,
>
> In my opinion the only really important thing to be cleaned up before
> releasing a first
> version of the ALSA driver is the damn ugly Chip'n Dale bug. I think
> that having more insight
> of the real meaning of the arguments of the function
> vortex_src_setupchannel() would help
> a lot finding this out. Indeed the argument marked as "?" are totaly
> unknowm, and by know i just
> figured out some values that "just work" for the AU8820 but not for the
> AU8830.
>
> vortex_src_setupchannel(vortex, src, cvrt, 0, 0, ?, dir, 0, 0, ?);

playing a 44100 stereo stream causes the binary driver to do the
following:

CAsp4Src::SetupChannel(cba70c04, thisc:0, cvr: aab, b: 0, c: 0, d: 0, e:
1, f: 0, g 2731, thsource: 1)
CAsp4Src::SetupChannel(cba70c04, thisc:0, cvr: 3acd, b: 0, c: 0, d: 1, e:
1, f: 0, g 15053, thsource: 1)
CAsp4Src::SetupChannel(cba70c14, thisc:1, cvr: 3acd, b: 0, c: 0, d: 1, e:
1, f: 0, g 15053, thsource: 1)
CAsp4Src::SetupChannel(cba70c04, thisc:0, cvr: 3acd, b: 0, c: 0, d: 1, e:
1, f: 0, g 15053, thsource: 1)
CAsp4Src::SetupChannel(cba70c14, thisc:1, cvr: 3acd, b: 0, c: 0, d: 1, e:
1, f: 0, g 15053, thsource: 1)

adding another one does this:
CAsp4Src::SetupChannel(cba70c24, thisc:2, cvr: aab, b: 0, c: 0, d: 2, e:
1, f: 0, g 2731, thsource: 1)
in 8
CAsp4Src::SetupChannel(cba70c24, thisc:2, cvr: 3acd, b: 0, c: 0, d: 3, e:
1, f: 0, g 15053, thsource: 1)
in 8
CAsp4Src::SetupChannel(cba70c34, thisc:3, cvr: 3acd, b: 0, c: 0, d: 3, e:
1, f: 0, g 15053, thsource: 1)


> The last argument, is either 0 or 1 (it sets the "throttle source" bit).
> The 6th argument could be upto 4 bit wide, and it semes to be related
> with the SRC number being
> used (not necesarily true). The AU8830 and AU8820 have 16 SRC's so that
> fits.
>
> The current driver uses for each ADB DMA channel the SRC's i*2 and
> i*2+1, where i is the number
> of the ADB DMA channel. This isn't the best alternative, but it ensures
> that there are always 2 SRC
> avaiable for each ADB DMA channel.
> The AU8830 has 32 ADB DMA channel and only 16 SRC: No idea how this
> should fit together.
>
> There are 32 or 64 WT DMA channels, but they are handled different. They
> have bo routes for the SRC stuff.
> They have Statically routes SRC inside of the "WT" block, an the output
> of the individually processed
> channels are routed somewhere (ADB addresses are unknown) to the codec.
> THere is a generic
> wt_setregister() functions, which i suspect is the one used by the
> WaveTable engine to control the
> WT channels block, to change SRC settings, and possibly some special
> effects. The code for doing this
> is not contained in the Linux binary driver, so if we want to implement
> the WaveTable we need to
> sniff the Windows driver. Disassembling it is rather useless, inserting
> a sniffer would be easier.
> Can anybody recommend a tool to disassemble, modify and recompile L type
> VXD's ? Maybe
> a cracking tool :) ?

In addition to this, has anyone ever done any windows driver development,
or know a way to get raw access to a pci device from user space?

>
> So, i'm extremely busy right know, so i wanted to ask if someone else
> could take a look at this ?
> I could continue working on this issue in about 2 weeks, but come one
> guys, specially those who
> havent coded anything, this your chance to do something really cool
> important. This code will
> be part of the linux kernel 2.6 some day :) !!

If no one else stands up to claim this, I'll take it. I had a look at
it before, but couldn't get much out of it...

-Jeff





reply via email to

[Prev in Thread] Current Thread [Next in Thread]