Bug 55795
| Summary: | soundblaster live sound issues 2.4.9-6 | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | penguins |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED NOTABUG | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | fdjsouthey, ktsaou, shishz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | athlon | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2002-05-03 05:30:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
penguins
2001-11-06 20:14:00 UTC
I have the same problem with both 2.4.9-6smp and 2.4.9-12smp on an i686 platform. 2.4.3-12smp works without problems. It seems that sox (the prog behind play) leaves the dsp in an undefined state or that it does not initialize the dsp correctly. GNOME and KDE sounds work perfectly. This occures only to SBLive (emu10k1 module), other soundcards I have tested work correctly. It may be helpfull to note that if you use play before you start KDE or GNOME, the first sound played by the GUIs has a very sort scratch in the beginning. It seems like the dsp has some garbage data in its buffers... After that scratch KDE and GNOME continue normally. I also noted that play is sometimes capable to play wavs correctly after KDE and GNOME have been started but I was unable to find a pattern. Somehow, some program left the dsp in a good state for play to work correctly. Of course after the first wav the others produce noice. Is this fixed by the emu10k1_new extra driver in the -21 erratum ? No. 2.4.9-21 still has these problems. I have found that the HIGHMEM kernel option is causing this. I've compiled 2.4.15 with and without HIGHMEM and I verified that with HIGHMEM turned on, it distrorts the sound, while without HIGHMEM it works perfectly. Did you try the emu10k1_new <--- spot the _new driver ? Oooops! No, I have not. I'll try it and I'll let you know later today. (sorry for not understanding that by _new you ment a completelly different driver :-) ok. I installed the '_new' module. Here are my findings: a. KDE/GNOME work without the initial scratches b. The 'play' command: Sometimes, produces garbage (distortion). A few times produces no sound. A few times it plays correctly. I have verified the following pattern: play xxx.wav => correct sound same command repeats succesfully a few times (1 to 5) play xxx.wav => no sound or total distortion playwave xxx.wav => [sometimes scratch, followed by] correct sound playwave xxx.wav => correct sound play xxx.wav => correct sound same command repeats succesfully a few times (1 to 5) play xxx.wav => no sound or total distortion playwave xxx.wav => [sometimes scratch, followed by] correct sound playwave xxx.wav => correct sound etc. c. Sometimes KDE produces scratches before the sound, especially when there is some use of the 'play' command concurrently. I have the same problem. The emu10k1_new driver did not fix the problem. I have: SoundBlaster Live Value 900 Mhz Athlon Abit KT7 Motherboard (KT133 chipset) 770 MB PC 133 SDRAM Asus V7700 (GeForce2 GTS) running latest "nv" driver D-Link (530-TX?) PCI NIC RedHat 7.2 (kernel 2.4.9-31) "play" causes problems, not with all samples, but with many. "playwave" is much more reliable. XMMS/mpg123 works just fine. I see much the same behaviour as described in the previous comment. Please let me know if there's anything else I can test, try, or report on. I'd love to see this fixed. Every so often I hit a web page with samples and it's excruciating. |