DMASOUND->rev6 (2.4.3)(attn: Xine, MOL, PowerComputing, ibook, Tumbler)

DMASOUND->rev6 (2.4.3)(attn: Xine, MOL, PowerComputing, ibook, Tumbler)

[Iain Sandoe]

Hi List, Paul, Ben,

Here is the (long promised) rev 6 patch for dmasound:

-----

To build it you need to apply:

ftp://ftp.penguinppc.org/users/iain/kernel/2_4_x/2.4.3-final/dmasnd-2.4.3-fi
nal.diff.bz2

*and*

ftp://ftp.penguinppc.org/users/iain/kernel/2_4_x/2.4.3-final/dmasnd-2.4.3-to
-rev-6.diff.bz2

to a BK, Paulus (and prob. Benh) kernel later than 2.4.3-pre3.

----

binaries/SystemMaps/Modules:
ftp://ftp.penguinppc.org/users/iain/kernel/2_4_x/2.4.3-final/

the binaries are identified by -i138 and -i138-blt-in for module and
built-in respectively.

Please include the "i138" in any bug report -it's my local BK cset
identifier for the patch.

the BK baseline for these was 1.137 (IIRC).

-----

what's been changed (and who might be interested ;-) :

 - fix bug: where sample rates higher than maximum were
   being reported as OK.
   (xine, Paulus)

 - fix bug: open() now returns -EBUSY as per OSS doc. when
   audio is in use - this is independent of O_NOBLOCK.
   [this is ifdef'd at the moment in case anyone thinks that
    OSS is wrong - and it *should* block ;-)]
   (MoL, Paulus)

 - fix bug: where SNDCTL_DSP_POST was blocking.
   (MoL, Paulus). [untested]

 - incorporate mixer changes from 2.2.x back-port.
 - take out passthru as a rec input (it isn't).
 - make Input Gain slider work the 'right way up'.
 - try to make the mixer sliders more logical - so now the
   input selectors are just two-state (>50% == ON) and the
   Input Gain slider handles the rest of the gain issues.
 - try to pick slider representations that most closely match
   the actual use - e.g. IGain for input gain...
   (anyone with Screamer or AWACS based machines)

 - first stab at over/under-run detection.
    (everyone - reported in /dev/sndstat)

 - minor cosmetic changes to IRQ identification.
   (everyone)
 - make use of i2c for mixer settings conditional on perch
   rather than cuda (some machines without perch have cuda).
    (machines with cuda but without perch ;-)

 - fix bug where TX stops when dbdma status comes up "DEAD"
   so far only reported on PowerComputing clones ... but.
   (PowerComputing clones - NOT TESTED - please let me know what happens).

 - put in AWACS/Screamer register write timeouts.
 - part way to partitioning the init() stuff
   (just tidying up + cater for move to separate files for each codec)

 - make more attempt not to write anything where we shouldn't for DACA
   (ibook owners).

 - first pass at 'tumbler' stuff (not support - just an attempt
   to allow the driver to load on new G4s).
   (New G4 owners - *don't* try the built in until you've tried the module..
   it may still lock up - UNTESTED - let me know what happens)

====
It's been tested on G3/Beige, Lombard & 9600/233 --- it might *break* on
anything else.... let me know.
=====

If this is OK, I will start to integrate the iBook i2c mixer control code...
and (as soon as I get *any* info on it) similar stuff for "tumbler" (new
G4s).  BUT... this is quite a big change...

next on the TODO: implement SNDCTL_DSP_GETXPTR and friends (xine, MoL).

I'm still keen to get hold of something burgundy-based so that I can make
similar changes to the burgundy mixer code.  Any offers?

happy testing,
ciao,
Iain.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: DMASOUND->rev6 (2.4.3)(attn: Xine, MOL, PowerComputing, ibook, Tumbler)

[Iain Sandoe]

I wrote:
> -----
>
> what's been changed (and who might be interested ;-) :

but forgot to add:

Keylargo rev 2 is now detected and H/W byte swap disabled if it is seen.
[untested].

If any G4/tumbler people get action (AFAICT this is Keylargo Rev3) could
they tell me if that needs to be picked up too?

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: DMASOUND->rev6 (2.4.3)(attn: Xine, MOL, PowerComputing, ibook, Tumbler)

[Henry Worth]

Applied to 2.4.3-benh, it is still reporting back 48K.
>From the new /dev/sndstat it looks like it is trying to
resample, but if it is, it is doing a terrible job. But,
it falls so far behind and drops pitch enough, that
it still must not be resampling above 44.1K. I don't
see anything in the patches that would change the
old behavior, did Paulus' fix get lost?

Xine will resample just fine if the device would
simply respond back to the SNDCTL_DSP_SPEED that 44.1K
was set instead of 48K. There is no need to extend kernel
resampling to 48K, any apps broken in this regard are
going to be broke on many x86 platforms.

In case I've got the wrong level:

PowerMac (AWACS rev 3 [screamer])  DMA sound driver rev 016 installed
Core driver edition 01.05 : PowerMac Built-in Sound driver edition 00.05
Write will use    4 fragments of   32768 bytes as default
Read  will use    4 fragments of   32768 bytes as default

/dev/sndstat :

PowerMac (AWACS rev 3 [screamer]) DMA sound driver rev 016 :
Core driver edition 01.05 : PowerMac Built-in Sound driver edition 00.05
		 === Formats & settings ===
Parameter                 soft                hard
Format   :    signed 16 bit BE    signed 16 bit BE
Samp Rate:         48000 s/sec         44100 s/sec
Channels :              stereo              stereo
		 === Sound Queue status ===
Allocated: Buffers  Size
    write:       4 32768
     read:       0     0
Current  : MaxFrg FragSiz MaxAct Frnt Rear Cnt RrSize A B S L  xruns
    write:      4    7528      4    0   -1   0      0 0 0 0 0      0
     read:      0       0      0    0    0   0      0 0 0 0 0      0

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: DMASOUND->rev6 (2.4.3)(attn: Xine, MOL, PowerComputing, ibook, Tumbler)

[Iain Sandoe]

Hi Henry,

> Applied to 2.4.3-benh, it is still reporting back 48K.

>
> In case I've got the wrong level:

'fraid so...

> PowerMac (AWACS rev 3 [screamer])  DMA sound driver rev 016 installed
> Core driver edition 01.05 : PowerMac Built-in Sound driver edition 00.05
                        ^^^                                            ^^^
the fixes are in in 1.06          0.06

- you  need to apply *both* posted patches -final first and then -to-rev6
(or try the binaries).

ciao,
Iain.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: DMASOUND->rev6 (2.4.3)(attn: Xine, MOL, PowerComputing, ibook, Tumbler)

[phandel]

On Thu, 5 Apr 2001, Iain Sandoe wrote:

> Please include the "i138" in any bug report -it's my local BK cset
> identifier for the patch.
[snip]
>  - fix bug where TX stops when dbdma status comes up "DEAD"
>    so far only reported on PowerComputing clones ... but.
>    (PowerComputing clones - NOT TESTED - please let me know what happens).

Nope, I can still kill sound by merely moving the mouse.  Here is the new
line from the console:

Apr  7 03:31:13 like kernel: dmasound_pmac: tx-irq: xfer died - patching
it up...

...but sound is dead, along with the player app, just as before.

This was with Paul's 2.4.3 (slight patch to work around missing
process_bridge_ranges) and both patches you mentioned in this email.



Thanks,
Peter


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: DMASOUND->rev6 (2.4.3)(attn: Xine, MOL, PowerComputing, ibook, Tumbler)

[Iain Sandoe]

>>  - fix bug where TX stops when dbdma status comes up "DEAD"
>>    so far only reported on PowerComputing clones ... but.
>>    (PowerComputing clones - NOT TESTED - please let me know what happens).
>
> Nope, I can still kill sound by merely moving the mouse.  Here is the new
> line from the console:
>
> Apr  7 03:31:13 like kernel: dmasound_pmac: tx-irq: xfer died - patching
> it up...
>
> ...but sound is dead, along with the player app, just as before.

damn... so much for the dbdma manual... :-(

what do you _have_ to do to re-start the sound?
kill & re-start the app?
close & re-open /dev/dsp?
un-load & re-load the module?
- or reboot?

can you make sure it's not the app that's stopping?
(or is this equally the case with _any_ app?)

If you have a big-ish file (although it doesn't sound like you need very
big) then my stest program would do to test it... it's *very* simple and
therefore should eliminate lots of other possibilities ;-)

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: DMASOUND->rev6 (2.4.3)(attn: Xine, MOL, PowerComputing, ibook, Tumbler)

[Iain Sandoe]

]
>>  - fix bug where TX stops when dbdma status comes up "DEAD"
>>    so far only reported on PowerComputing clones ... but.
>>    (PowerComputing clones - NOT TESTED - please let me know what happens).
>
> Nope, I can still kill sound by merely moving the mouse.

This is beginning to  worry me - I can't see what it has to do with the
disk-sound interaction we were originally talking about.

(did I ever get your dev-tree? - I can't find a mail with it...).

when you move the mouse:

via-cuda (?)
...
move cursor in display driver (*PCI* , I guess?).

does the problem occur if you press & hold a key?
(i.e. is it the adb end or the display driver end?)

what display device?
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: DMASOUND->rev6 (2.4.3)(attn: Xine, MOL, PowerComputing, ibook, Tumbler)

[phandel]

On Sat, 7 Apr 2001, Iain Sandoe wrote:

>
> >>  - fix bug where TX stops when dbdma status comes up "DEAD"
> >>    so far only reported on PowerComputing clones ... but.
> >>    (PowerComputing clones - NOT TESTED - please let me know what happens).
> >
> > Nope, I can still kill sound by merely moving the mouse.  Here is the new
> > line from the console:
> >
> > Apr  7 03:31:13 like kernel: dmasound_pmac: tx-irq: xfer died - patching
> > it up...
> >
> > ...but sound is dead, along with the player app, just as before.
>
> damn... so much for the dbdma manual... :-(
>
> what do you _have_ to do to re-start the sound?
> kill & re-start the app?
> close & re-open /dev/dsp?
> un-load & re-load the module?
> - or reboot?

The application is wedged (at least the sound-playing thread) - ie. in
xmms, I can still use the menus etc. but the timer itself has stopped.
If I try to quit xmms, xmms will freeze completely.  I then *have to* kill
xmms (so that I can unload the two sound modules dmasound_{pmac,core}),
unload the two modules, and then reload the two modules.  Rebooting is not
required.

Here is the message after the insmod:

Apr  7 13:46:55 like kernel: dmasound_pmac: Awacs/Screamer Codec Mfct: 2 Rev 2
Apr  7 13:46:55 like kernel: PowerMac AWACS rev 2  DMA sound driver rev
016 installed
Apr  7 13:46:55 like kernel: Core driver edition 01.06 : PowerMac Built-in
Sound driver edition 00.06
Apr  7 13:46:55 like kernel: Write will use    4 fragments of   32768
bytes as default
Apr  7 13:46:55 like kernel: Read  will use    4 fragments of   32768
bytes as default


> can you make sure it's not the app that's stopping?
> (or is this equally the case with _any_ app?)

Yes, it happens with any app.

> If you have a big-ish file (although it doesn't sound like you need very
> big) then my stest program would do to test it... it's *very* simple and
> therefore should eliminate lots of other possibilities ;-)

I can kill sound with xmms, mpg123, realplay, etc. although I can't kill
it with realplay at low bitrates.

Another datapoint: It seems as if I can kill sound more easily when I play
mp3s that reside on my fast drive -> I can kill it within 30sec from the
IBM 7200rpm UltraSCSI drive, but it takes a few minutes of playing from
the Seagate 5400rpm UltraSCSI drive.


Thanks,
Peter


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: DMASOUND->rev6 (2.4.3)(attn: Xine, MOL, PowerComputing, ibook, Tumbler)

[Iain Sandoe]

On Sat, Apr 7, 2001, Peter wrote:
> On Sat, 7 Apr 2001, Iain Sandoe wrote:
>> >>  - fix bug where TX stops when dbdma status comes up "DEAD"
>> >>    so far only reported on PowerComputing clones ... but.
>> >>    (PowerComputing clones - NOT TESTED - please let me know what happens).
>> >
>> > Nope, I can still kill sound by merely moving the mouse.  Here is the new
>> > line from the console:
>> > Apr  7 03:31:13 like kernel: dmasound_pmac: tx-irq: xfer died - patching
>> > it up...
>> >
>> > ...but sound is dead, along with the player app, just as before.

It's disappointing that the sound won't re-start... (with Kostas' tests - it
_was_ - just from the 'wrong' place).

> Another datapoint: It seems as if I can kill sound more easily when I play
> mp3s that reside on my fast drive -> I can kill it within 30sec from the
> IBM 7200rpm UltraSCSI drive, but it takes a few minutes of playing from
> the Seagate 5400rpm UltraSCSI drive.

Hmmm. I'm getting a bit confused... the disk problem we think we (might)
understand - the mouse one is different, maybe ?

I need to get a report from Kostas - because I don't (think) he has the
mouse problem?

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: DMASOUND->rev6 (2.4.3)(attn: Xine, MOL, PowerComputing, ibook, Tumbler)

[Michael Schmitz]

> Hmmm. I'm getting a bit confused... the disk problem we think we (might)
> understand - the mouse one is different, maybe ?

Why? Both the disk and the mouse interface cause interrupts to happen ...

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: DMASOUND->rev6 (2.4.3)(attn: Xine, MOL, PowerComputing, ibook, Tumbler)

[Iain Sandoe]

>> Hmmm. I'm getting a bit confused... the disk problem we think we (might)
>> understand - the mouse one is different, maybe ?
>
> Why? Both the disk and the mouse interface cause interrupts to happen ...

yes, but the fault we are trying to fix is supposed to be a PCI timing bug
;-)

hence my earlier rambling about mouse moves .... -> updates cursor (via PCI
to graphics card)...

or maybe there are two faults...

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/