[Openvortex-dev] Re: [Alsa-devel] au8830+via & alsa 0.9.7c

[Wilfried Weissmann]

Manuel Jander wrote:
> Hallo Wilfied,
>
> On Mon, 2003-10-20 at 16:37, Wilfried Weissmann wrote:
[snip]
> > au88x0 instead of the bus-bridge). but i thought that the fix was 
> > already in the driver. afterwards i had a look at the sources and could 
> > not find code that would do this. is there another workaround in the 
> > driver (apart from the loop with a counter around the 
> > vortex_fifo_setadbctrl() that stopps the kernel from freezing) or is it 
> > just not in there?
>
>
> Well, you just confirmed me that there was really a bug in the old
> binary driver. The old binary driver keeps looping with some locks held
> for a hardware flag that never changes, freezing your computer. Jeff
> Muizelaar added a "lifeboat" to that loop, but very later we noticed
> that this semes to help stability. Now we have the proove :D

are there plans to include the pci fix into the driver? i think the 
cs46xx does something similar by detecting if it is run on a thinkpad 
and enabling some workaround if required. it should be pretty 
straightforward. just look if the pci-id of the via northbridge can be 
found on the pci bus and then set the registers according to the test 
result. if you want a patch for that then i could make one at the next 
weekend.

> > there is also somewhere a bug in recording (unless this is caused by 
> > still running on the 0.9.6 libs. i will upgrade that soon.). i 
> > discovered it when i used speakfreely with alsa support. in one second 
> > intervals there was some loud noise that sounded like garbage data. when 
> > i compiled speakfreely with oss support and linear audio then the 
> > distortion was gone. with "arecord -f MU_LAW -r 16000 -t au x.au" i can 
> > reproduce something similar. this time there is 1 second of normal 
> > audio. for few milliseconds there appears some short sample from the 
> > previous second again. then 1 second of normal playback and a sample 
> > from that is also played again....
> > it feels like that the buffer does not have the right size. if you 
> > choose higher sampling rates, 16-bit samples and stereo then the samples 
> > that are played twice are getting shorter and finally the problem 
> > disappears. any ideas?
>
>
> This could be a period size bug. I didn't test the Alaw support myself,
> but know i see that it could be useful for VoIP.

i just did some more testing after upgrading the libraries and utils to 
version 0.9.7 to get you some details. i recorded samples with arecord 
in mu-law mono with a sampling rate from 8khz to 48khz in 2khz steps. 
8khz is fine. but the samples from 10khz to 32khz are getting worse with 
increased sampling rate (contrary to what i said before). 34khz to 48khz 
have perfect sound again.
another funny thing is that at first i recorded a sample with 44100hz 
and then with 28000hz. and at the beginning of the 28000hz sample i 
found a low pitched snippet (due to the change is sampling rate) of the 
previous sample.

> > i am using kernel 2.4.22 tainted by NVidia.o(tm) on a athlon k7 800MHz 
> > box with a via kt133 chipset. the distribution is debian-sarge 
> > (testing). no alsa plugins are used.
>
>
> Great to here that story :D
>
> Best Regards
>
> Manuel Jander

bye,
wilfried