login
Search
I feel bad about bringing this one up because I honestly have no idea
*when* the driver quit working. (I don't always have a spare set of
speakers available for the Alpha). This literally could have been
broken for months...
Symptoms:
(1) Using the sox-based "play" command to play a short ".wav" file
results in the file being played approx. 1.5 times, i.e., it plays
all the way through, then restarts from the beginning and quits
somewhere in the middle of the second playback. At least the
sound doesn't seem distorted...
(2) Using "mpg123" results in silence at first, then after about 30
seconds, a tight loop of random repeating sound (doesn't sound like
part of the mp3 file, but it's probably derived from it :-)) until
the process is forcibly killed.
I have to hit <ctrl>C twice to interrupt playback.
/proc/asound/cards looks normal:
0 [ES1888 ]: ES1888 - ESS AudioDrive ES1888
ESS AudioDrive ES1888 at 0x220, irq 5, dma1 1, dma2 5
Here are the ALSA module options I've always had defined in
/etc/modprobe.d/sound:
alias snd-card-0 snd-es18xx
alias sound-slot-0 snd-es18xx
options snd-es18xx enable=1 isapnp=0 port=0x220 irq=5 dma1=1 dma2=5 mpu_port=0x330
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
rct@frus.com | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
--
Sounds like a DMA screwup. However, I'm pretty sure that it's not a generic ALSA problem with ISA DMA, as my good old GUS MAX still works perfectly on lx164 (machine that is very similar to your miata) as I wonder if it still works on x86 - perhaps you ought to ask ALSA folks. I'll search my machine room next week - I recall that there were a dozen of old ISA soundcards, maybe there is some es18xx stuff, but chances are slim... Ivan. --
Agreed. There's a comment line near the top of the es18xx.c that has been there for a *long* time: Support for 16 bit DMA seems to be broken. I've no hardware to tune it. Supposedly with the ES1888, dma1 is for capture, dma2 is for playback. dma2 == 5 is a 16-bit channel, yes? That could explain much... As for the values "chosen" for dma1 and dma2, they are the ones that keep showing up in the Alpha sound "howto" postings/documents. The driver can cope with dma1 == dma2 by enforcing half-duplex mode in software, but the OSS "sb" driver works fine with the indicated DMA channel values. Besides, if the ES1888 is really capable of full-duplex I tried contacting the driver authors as indicated in the driver source file. Christian Fischbach seems to have disappeared. Still waiting to hear from Abramo Bagnara. -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
Running 'show config' in SRM on my Alphas (PWS500au and XP1000) reveals the settings (except possibly for mpu_port) for the ESS1888 sound chip. I recall that they are as reported in Alpha sound howtos. I hadn't been using the ESS1888 for awhile, but have just tried it out since you reported problems. I am running kernel 2.6.24.3 and Debian testing on the XP1000. I tried playing a number of wav files with alsa's aplay, sox's play and with mocp. I found that aplay and mocp worked reliably through the ESS1888. Sox's play on some files did play back a small extra segment of the file - particularly on short files and usually some section near the end of the file - once it had completed playing the file once; maybe this is what you are also observing. More onerously, my testing eventually ended in a complete system lock up! I ran play (or was it aplay - sorry can't remember now) and the system locked up. Got a response with ping across the network but couldn't log in via ssh. Have been playing mplayer through the ESS1888 for the last couple of days (don't like it though - the sound quality of the ESS1888 is not good enough for my ears) and haven't had another one of those lockups since. Cheerz Michael. --
Can it be forced to use dma2=0 (an 8-bit channel, and the usual capture This sounds very suspiciously like a difference with playing through the native ALSA interface and the OSS emulaion. Could you and/or Bob confirm that sox is using the OSS emulation and not ALSA natively? I could very well imagine the ALSA OSS emulation being broken on Alpha. I doubt any of teh developers has an Alpha. And if aplay works correctly this seems very likely. "sox" _can_ use ALSA natively as well by the way (see manpage for the Mmm. Rene. --
dma2 is for playback, I'm having playback problems, dma2 == 5 is a a 16-bit channel, and 16-bit DMA is an issue with the es18xx driver I'll try a few things like dma2 == dma1, and setting dma2 to an 8-bit channel, but I think the various configuration parameters are hard-wired I'll see if I can verify whether it's a native ALSA vs. OSS emulation issue. The local version of sox (Debian 12.7.9-1) contains a library dependency on libasound.so.2, and a "strings" on the binary yields "ALSA_0.9.0rc4" as well as several ALSA error message strings. However, output by default goes to /dev/dsp (major 14, minor 3), which is definitely OSS. -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
Settable through BIOS perhaps? But anyways, if it used to work, it should work and I really suspect it's just a matter of a broken OSS emulation on alpha anyways. In fact, I fairly distinctly remember this being an issue not too long ago but google is coming up empty... That's an expected string and very likely doesn't mean you have a 0.9.0-rc4 alsa-lib installed. "strings [ ... ] | grep ^ALSA_" probably shows a few later versions as well. But if the problem's the (kernel) OSS emulation then userspace dopesn't matter anyway. You seem to have sox installed, so try $ sox foo.wav -t alsa default and $ sox foo.wav -t ossdsp /dev/dsp to have it play through the ALSA and OSS interfaces, respectively. Rene. --
Playback results in infinite loop over the first quarter second or so of audio. Using "aplay" results in same looping behavior over a longer Identical results to using "play" (as expected): for the 50K ".wav" file, I hear the entire file approx. 1.8 times. I tried a few rmmod/insmod cycles with different values for dma2. Results as follows: (a) dma2=1 (== dma1): no change (b) dma2 option omitted : no change (c) dma2=-1 : probe failed -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
At Mon, 10 Mar 2008 17:56:49 +0100, No, I don't know of. OSS emulation code is written fairly independently from architectures. Maybe just a missing CONFIG_SND_PCM_PLUGINS kconfig? Takashi --
Could've sworn... The bug seems not present on x86. I'm testing with a ES1968 and ES1898 (his is a 18888) and playback through ALSA native nor OSS emulation is giving me trouble up to now. Bob? How short are "short" wav files by the way? Rene. --
The one I was using for testing is 50,272 bytes. A slightly longer file that exhibits "more exotic" looping behavior is 97,898 bytes (just a bit over 6 seconds of audio). I'll send you the shorter file under separate cover. -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
Thanks. No problems here, using either the ALSA or OSS interfaces. Have been busy switching cards -- I have no hardware that can use anything other than DMA 0, 1 or 3. First test is to see if it's ALSA or just the OSS emulation though... Rene. --
Both native ALSA and emulated OSS playback are broken based on last night's testing. Just to rule out sound hardware issues, this morning I built a 2.6.25-rc4 kernel with OSS (sb driver), and that seems to be working fine. -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
... and this isn't. Worse yet, we have a conflicting report from Michael where things are fine while using aplay and I'm seeing nothing particularly suspicious recently. I suppose it used to work and I suppose the behaviour you are describing above is 100% repeatable? Given that you can use aplay -- probably no difference with "aplay -M" ? To get to the bottom of this we might need to get a specific failed version (for readers, it's not been verified that this is a regression since 2.6.24) but we can try to get lucky first. The most recent change to sound/isa/es18xx.c that's not utterly impossible to have made a difference is 1bc9eed379399484d3f5d5a0834674983969bc1, "es18xx: Enable wavetable input from ESS chips". I don't know if you're a GIT user. If you are, you can revert it simply with $ git revert 1bc9eed3 If you're not a GIT user, applying the attached should work. Unlikely, but Okay. A and B seem to at least confirm it's not the 16-bit DMA. Rene.
I can't tell you exactly *when* it used to work, or even *if* it did with 2.6 kernels. I'll try to explain... Sometime back in the 2.6.14 to 2.6.16 timeframe there was an issue with the ALSA driver not recognizing interrupts (causing looping). Tyson Whitehead had put together a patch for the interrupt problem that worked for him, but not for me or Michael. One workaround back then was using the snd-sb8 driver that supports only one DMA channel (half-duplex operation) anyway: that was a reliable workaround, and may be what I'm remembering for the "it used to work" case. I can't find any reliable evidence that I've *ever* been able to use the ES1888 with its proper driver under ALSA with 2.6 kernels. As far as Tyson's patch, I know he reported it upstream to the ALSA developers, but I saw no followup I'm beginning to think this is *not* a regression, but merely a long- standing ALSA issue that was never addressed. I would be fine with reclassifying this as an ALSA bug and dropping linux-kernel from the As far as how to proceed from here, I'm certain things were broken in 2.6.1[4-6]. I could try various later releases between .16 and .24 to see if snd-es18xx worked for any of those, but I think the answer will be "no." I think a useful test would be to see if "snd-sb8" works in 2.6.25-rcX, which would at least narrow things down a bit. -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
Yes, the ESS1888 driver failed to work on Alpha about the 2.6.14 to 2.6.16 kernel. It came right with alsa release 1.0.13 (IIRC) and I have been running the ESS1888 driver on an Alpha XP1000 without problems for about a year. I have been using mocp and mplayer on a fairly regular basis. My Mplayer version uses the OSS interface by default. Not sure, off-hand, what mocp is using. For the last three months I have been playing with other sound cards (the quality of sound from the ESS1888 leaves a lot to be desired, imho) and haven't used the ESS1888 recently, so if a regression has been introduced after kernel 2.6.22 then it is likely I wouldn't see it. Sorry, but I am not in a good position to do testing of the ESS1888 at the moment. A week or so ago my system and home partitions shat themselves and I had to reinstall from 3 month old backups. It has just happened again - two nights ago. Don't know what is causing it - whether it is hardware fault (I can't find any disc block errors), the 2.6.24.2 (and 2.6.24.3) kernels I had recently upgraded to, or the recent update from Debian testing, or the switch from the internal SCSI card and disc to an installed SATA card and disc that I did three months ago (though that one has worked for the first two and a half months without flaw). Maybe I should start a new thread with a report of that just in case it is a kernel problem??? Michael. --
Nod. I take it things were working for you at least as recently as 2.6.22, then. I can try that version and see if it works for me. My situation is that I can't swear I've tried anything involving ALSA on the Alpha since 2.6.16 until recently, so I'm not sure this is really a regression in my case. Because I threatened to do it :-), I built a 2.6.25-rc4+iommu_patch kernel with both the snd-es18xx and snd-sb8 modules available. As hoped (expected?), the snd-sb8 driver works fine. This would imply the problem is at least somewhat specific to the es18xx driver, and that the underlying ALSA infrastructure is reasonably healthy (notice that I intentionally avoided saying it was "sound" -- sorry, I never could pass on low-hanging fruit). -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
Well, I built a 2.6.22 kernel last night, and in tests this morning there's no difference relative to the ALSA behavior seen in 2.6.25-rc4. Since the question came up (or was strongly implied), I took the time to check the status of IRQ 5 in /proc/interrupts, and while it shows up as assigned to the sound card, no interrupts are being seen/processed by the es18xx driver. When I remove the snd-es18xx module and install the snd-sb8 module with the same parameters (other than there's no second DMA channel), the /proc/interrupts counter for IRQ 5 increments as expected when playing sound files. At this point I'm pretty sure the es18xx issue isn't a regression: it's "just" a bug that has been around since I first loaded 2.6.X on my Alpha. -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
Okay. If someone is tracking this as a 2.6.25 regresion, it can be stricken What does cat /proc/config.gz | grep CONFIG_ALPHA_ say? Miuchael, and for you? For some Alpha configs, arch/alpha/kernel/es1888.c is compiled and for some not. I expect for you (Bob) it's compiled in? And Michael? Rene. --
Here is the requested list of CONFIG_ALPHA_* items for the
2.6.25-rc4+iommu_patch kernel with support for snd-es18xx and snd-sb8:
CONFIG_ALPHA=y
CONFIG_ALPHA_MIATA=y
CONFIG_ALPHA_EV5=y
CONFIG_ALPHA_CIA=y
CONFIG_ALPHA_EV56=y
CONFIG_ALPHA_PYXIS=y
CONFIG_ALPHA_SRM=y
CONFIG_ALPHA_LEGACY_START_ADDRESS=y
From arch/alpha/kernel/Makefile, obj-${CONFIG_ALPHA_MIATA} adds es1888.o
as a built-in object, so yes, it's built-in.
I never noticed the init support for the ES1888 chip before... The code
appears to set up DMA channel 1, but does not mention anything about the
second 16-bit DMA channel.
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
rct@frus.com | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
--
Okay, and applying the attached just makes your sound completely dead in the Indeed. It seems to init it as an sb8... Rene.
Oddly enough, the patch had no effect whatsoever (at least with the ALSA drivers: I didn't try building a kernel with the OSS "sb" driver). Just to make sure I wasn't "benefiting" from initialization inherited from a prior boot, I even powered-down the machine for 30 seconds before booting on the new kernel. snd-sb8 still works, and snd-es18xx is still broken (in exactly the same way as before). -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
Okay, thought I'd stare at this thing a bit -- there's no specific 1888 documentation available it seems but I did notice something in the 1878 datasheet which might mean something. The docs says that bits 0-1 are don't care for DMA but don't for IRQ, so could it possibly be as simple as the attached? 1878 sheet doesn't document register 0x7f, it seems... Assuming it's not just this, this thing is going to require quite a bit of trial and error and without the hardware this will be troublesome. I expect this is not it, since the arch init code also doesn't care about bit 0 when setting that same register for IRQ 5. If this is not it -- I'd try s/0x50/0x10/ in that line, even completely commenting out the IRQ setting line (with the arch code built in) and just generally frolic around 'till something blows up... Rene.
I'll try the below when I get back from my business trip (in approx. two weeks). Apologies for the inconvenience, but the Alpha hardly qualifies as a laptop :-). If someone else with a Miata (or other Alpha with the ES1888 sound device) cares to give this a try, I *will* be keeping up with my e-mail. --Bob --
I should be able to give this a go over Easter on a PWS500au, which, IIRC, is a miata system. As an aside, I have been using the ESS1888 on my XP1000 (in between system partition corruptions and restoring the system three times - I suspect a failing controller card which I have now removed) through the OSS interface for a couple of weeks without problems. This is indicative that the ESS1888 problem may be specific to certain Alpha models. Michael. --
I have been able to run some tests. BTW, it is a PWS600au I have. It has an ES1887 sound chip. The most important result is that it is not only the snd-es18xx driver that fails (often leading to complete system lockups) but I also installed a CM8738 based sound card and use of the snd-cmipci driver exhibits exactly the same symptoms as the snd-es18xx driver. Both of these drivers work find on the Compaq XP1000. I am testing with the 2.6.24.3 kernel. On the PWS600au I have compiled the kernel for the miata system and selected the EV56 cpu option. On the XP1000 I have compiled the kernel for a DP264 system and with the EV67 cpu option. In response to an earlier question by Rene I note that arch/alpha/kernel/es1888.o is added in as a built in object by both systems. The es18xx and cmipci drivers work fine on the XP1000. I base that observation on using a variety of software, such as mplayer and mocp, through both sound cards, mainly through oss, but also have tried alsa, over the last year for es18xx and for the last three or four months for cmipci. (I have noted that the M-Audio Revolution 7.1 sound card with the ice1724 driver fails to work and causes system crashes on the XP1000, but that's a different discussion). On the PWS600au I have been running aplay on a two minute or so long wav file (because that is what I have on that system and couldn't be bothered searching for short files like what Bob was having troubles with). I can play the file once (using aplay) without any problem. When I attempt to the play the file the second time all hell breaks lose, sometimes with a variety of pops and whistles out the sound card, and the system crashes or just completely freezes. Occasionally a kernel oops makes it into the logs. This happens for both sound drivers (es18xx driver into the ES1887 and the cmipci driver into the CM8738 sound card). I applied the patches of Rene (es18xx-trial-and-error.diff) and the patch provided by Takashi (with ...
Was there ever a follow-up in that thread? : http://mailman.alsa-project.org/pipermail/alsa-devel/2008-March/006513.html There's a patch attached that disables mmap on MIATA. You and Bob seem to be experiencing problems of a different nature (or severity at the least) but for both of you it would be good to hear what applying this and then playing Thanks, that was of no use at all then; it was a bit optimistic indeed... The mmap thing is sort of the last hickup to be expected from me -- having no Alpha machines and with trouble not isolated to a specific driver nor Alpha model, this would at that point ideally want someone with some more Yes, thanks for the testing. There's an mmap in that last oops again at least... Rene.
Takashi replied with a suggestion to disable MMAP in the ice1724 driver. I have been preoccupied with other things for the last couple of weeks I have applied the patch to the PWS600au. Sound now works. I can play 8bit and 16bit sound files through the es1887 and the C-Media CM8738. They are both working fine. I managed to get a 32bit sound file to play through the M-Audio Revolution too. (Though another 32bit sound file just produces silence through the M-Audio Rev. Haven't been able to establish why - the file looks fine to me.) Repeated playing of files doesn't cause any problems. I can't get sox's play to work (reports no mmap support, which is, of course, quite true). I don't know how to tell sox to use the equivalent of alsa's hw device. So I can't do the test on short files that Bob was performing. At this stage I've run out of time to test the M-Audio Rev in the XP1000 and see if the MMAP disable patch help there. Michael. --
Thanks much for the quick reply. That's good to hear. As indicated, Bob seemed to be experiencing something else but this is pretty fundamental so I'll not try to comment on his case any further until he's had a chance to test this as well. Takashi -- over to you for Michael's issue? His PWS600AU (MIATA) system soils itself badly when using SNDRV_PCM_INFO_MMAP. His XP1000 works fine and I haven't the faintest clue if switching on CONFIG_ALPHA_MIATA is the proper switch, nor if outright disabling mmap is the correct approach. The patch that works for him is attached again for reference. The way this does the disabling also implies disabling SNDRV_PCM_INFO_IOMEM $ sox foo.wav -t alsa hw should do it. Here's a file Bob passed me as a problematic one. 8-bit, 11025, mono: Given that it fixes es18xx and cmipci on the PWS600au and that those worked without trouble on the XP1000, you'd _expect_ not, but the OOPs you posted before seemed to indicate that it stands a fair chance afer all. Rene.
Right, got that. On the PWS600au it shows the same problems that Bob describes! When I play it with aplay (through the es1887) I get the last "pal" repeated at the end. When I play it with sox (also through the es1887) I get the words "current event" repeated at the end. Playing through the CM8738 also repeats the words "current event" at the end when playing with sox. But using aplay through the CM8738 only results in silence and aplay hangs. A ctrl-c successfully breaks it. I suspect you are right - the symptoms I have observed (complete system crashes) are separate from what Bob observes. One question I have is what is different about Bob's set up that enables the sound to work with mmap? On the XP1000 (which has an unmodified kernel 2.6.24.3) I managed to play the sound file once with aplay through the es1887 (and it repeated "pal" at the end). Then I tried using sox and complete silence resulted. No, it's just playing back at the wrong rate - everything is sounding slow and extremely flat - the silence is just the artefact of a little bit of silence at the start of the file being played at far too a slow sample rate. Even other client programs are affected - mocp is playing back music at a horrendously slow sample rate. Yuk. Hopefully a rmmod es1887 might fix that - but I can't test it to I send this message and shut down X. Anyway I really must start marking that pile of assignments I told the students that I would have done by tomorrow. Further testing will have to wait to later this week. Michael. --
Lovely, so different problem between you and Bob. When you (either of you) have some time for it again, could you try: $ sox asskickd.wav -w -t alsa hw $ sox asskickd.wav -w -r 44100 -t alsa hw $ sox asskickd.wav -w -r 44100 -c 2 -t alsa hw and report if things start working? First transforms into 16-bit, second Not a clue. Takashi -- is it possible that Bob wasn't using mmap to being with if he didn't do anything specific to not do so? And perhaps you guys have firmware settable options that touch that area of coherent DMA? Maybe even a specific chipset bug on his machine? No idea how No rush. Thanks for the current amount of testing already. Rene. --
Tight loop at the beginning of the file: rapid continuous repeat of approx. the first couple tenths of a second. Hitting <ctrl>C caused playback to advance to the next small section of the soundfile. Further <ctrl>C's did Several seconds of silence, followed by what sounded like continuous pitched machine-gun fire. Each <ctrl>C advanced through the file (the pitch of the Silence for longer than I had patience to wait :-). Hitting <ctrl>C several times finally got me to an even more rapid machine-gun fire than the previous test. As in the previous test, each <ctrl>C advanced further through the file, although the perceived increment was smaller. Still had to type <ctrl>\ to kill sox. -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
Right, that sounds just like the older PWS600au I have - the one with the ESS1888 - except that what Bob describes as machine gun fire, I thought was, ahem, flatulence. The newer PWS600au (with the ESS1887) plays the sound files correctly, except for the repeated bits at the end. Michael. --
Exactly the same as without the -w option. (BTW, I would've never have The words "current event" are no longer repeated at the end of playing. There is a click at the end of playing - hard to know whether it started to repeat something or whether it is truly at the end of the I have another PWS600au - a little older than the one I was testing on. It is slightly different in that its scsi controller is a separate board in a PCI slot, rather than on the motherboard. Also has an ESS1888 rather than an ESS1887. Just installed the same OS and kernel on it. Tried playing sound. What a mess. Crashes with mmap on. Installed the patch turning off mmap. Just produces buzzes and fart noises whatever sound file I try to play; both with aplay and sox. Michael. --
Oh, by the way, note that it only disabled mmap for CONFIG_ALPHA_MIATA due to your report of es18xx working fine on the XP1000, so you'll have to change that to CONFIG_ALPHA_DP264 for the XP1000 to actually test it there: (or just delete SNDRV_PCM_INFO_MMAP from the info structures in the driver as Takashi earlier instructed) Rene.
Made no difference for any of the "sox" tests, and "play" is still broken in the way it always has been. However, "aplay" generated an interesting error I haven't seen before: $ aplay asskickd.wav Playing WAVE 'asskickd.wav' : Unsigned 8 bit, Rate 11025 Hz, Mono ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to find an usable access for 'default' aplay: aplay.c:919: set_params: Assertion `err >= 0' failed. Aborted by signal Aborted... The ES18xx IRQ (5) is still not seeing any interrupt activity. I *think* the only thing I haven't tried is Rene's patch that plays around with the irqmask (es18xx_trial_and_error). I'll give that a shot and report back as soon as possible. -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
Add in the "-D hw" option to the aplay command when using the mmap disabled alsa sound. Michael. --
Thanks! I now get "Maybe yo<>Maybe yo<>Maybe yo<>Maybe yo..." in an endlessly repeating loop. <ctrl>C is sufficient to stop playback, however. Still no activity on IRQ 5 seen by the ES18xx driver. -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
Late this evening I starting building a kernel with the above patch applied. It should be ready for testing sometime tomorrow. Sorry for the delay. -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
As distributed, no change: still not seeing any activity on IRQ 5. I'll play around with it some over the next day or so. Observed: the alsa "snd-sb8" driver works fine. Question: how does IRQ setup differ between the sb8 and the es18xx drivers? If I can find some time, I'll try to figure that out... -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
A quick followup... Since we're in agreement this isn't a regression, I've updated my working source tree to 2.6.25-rc5. Built the new kernel with the patch to omit es1888_init(), and as near as I can tell, that function does nothing useful on the Miata platform. At the very least, not having it makes no difference to any of the ALSA drivers I've tried: snd-sb8 still works great, and snd-es18xx is still broken in the same way originally described at the beginning of this long thread. I'll try a build with the old OSS "sb" driver, and if that works ok, we may be able to do away with es1888_init() on the Miata. Tyson -- I think you have a Miata if I'm remembering correctly: can you confirm these observations? -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
I actually ran into some problems with my Alpha, and I haven't managed to g= et=20 get it full operational again yet. I replaced the CPU fan, installed the n= ew=20 aboot, and left it trying to recover the filesystems. It was an unhappy=20 story all around -- damn that CMD646 chipset, I was under the impression th= at=20 driver had acquired some recent fixups. Anyway, if this succeeds, I'll try= =20 and compile up a new kernel with the patch when I get a chance. With regard to the sound driver, the es18xx does endless looping on the fir= st=20 second or so of sound on my box (a PWS500au) unless I apply my patch, which= =20 just enables the alternative interupt detection code in the driver. Even=20 then, though, I believe it still only works in 8bit mode. The sb8 driver also works for me. For this reason, I basically decided to= =20 forget about my es18xx patch. It doesn't get me anything the sb8 driver=20 doesn't give me, and it forces me to keep compiling my own kernels. Cheers! -Tyson PS: The Debian 2.6.24 kernel actually panicked on me (instead of infinitel= y=20 looping on the first second of sound) when I tried the stock es18xx driver. =2D-=20 Tyson Whitehead (-twhitehe at uwo.ca -- MC-) Computer Engineer Dept. of Applied Mathematics, Graduate Student- Applied Mathematics University of Western Ontario, GnuPG Key ID# 0xF7666BFF London, Ontario, Canada
Could you attach that patch? Links I'm finding are to http://whitehead.apmaths.uwo.ca/~tyson/ Rene. --
Sorry about that. I finally graduated. : ) Cheers! -Tyson
Thanks, interesting. I see Bob already tried this without luck though. Also see you guys both have a ES1888, so somewhat odd. Rene. --
At Fri, 14 Mar 2008 21:18:19 -0400,
I vaguely remember about the patch... The patch below was on my local
tree but never pushed because of lack of testing. Does it work for
Maybe the problem is in a different place, then...
thanks,
Takashi
---
diff -r 82e6201fc907 sound/isa/es18xx.c
--- a/sound/isa/es18xx.c Mon Mar 17 14:36:24 2008 +0100
+++ b/sound/isa/es18xx.c Mon Mar 17 17:32:59 2008 +0100
@@ -765,9 +765,10 @@ static irqreturn_t snd_es18xx_interrupt(
/* Read Interrupt status */
status = snd_es18xx_mixer_read(chip, 0x7f) >> 4;
}
-#if 0
- else {
- status = 0;
+
+#ifdef CONFIG_ALPHA
+ if (!(status & (AUDIO1_IRQ | AUDIO2_IRQ))) {
+ /* status = 0; */
if (inb(chip->port + 0x0C) & 0x01)
status |= AUDIO1_IRQ;
if (snd_es18xx_mixer_read(chip, 0x7A) & 0x80)
@@ -777,7 +778,6 @@ static irqreturn_t snd_es18xx_interrupt(
status |= HWV_IRQ;
}
#endif
-
/* Audio 1 & Audio 2 */
if (status & AUDIO2_IRQ) {
if (chip->active & DAC2)
--
It certainly doesn't work at all without it. It is definetly not This looks like it should accomplish the same thing (assuming not bits get set in status on the initial attempt to read it), without affecting other platforms and possible the alpha if anyone has a card that just works for whatever reason. A better patch all around. : ) Cheers! -Tyson PS: I've managed to recover my disks, and the machine is compiling 2.25-rc5 even as I write. --
Ok... I'm back. Replies to the long queue of messages will be sent as I have time to try the various patches. Unfortunately, this does nothing to fix the ES1888 on my system. Same broken behavior as described previously. I'll try something else in the queue later today after I get some sleep... -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct@frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------ --
Okay. The thing that "fixed" Tyson was disabling mmap from the driver: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-March/006911.html It landed him in the same situation as you though, where that "asskickd.wav" mono, 8-bit 11025 file you sent me shows the same behaviour you reported. This might imply you weren't using mmap to begin with. You have no horribly obsolete alsa userland, nor an /etc/asound.conf or ~/.asoundrc? No change with "aplay -M"? If there is a change, you'd expect it to be Tyson's old behaviour which means blowing up the machine on subsequent plays, so be a bit careful... This one needs answer so as to possibly pin things down to format: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-March/006914.html Rene. --
Weird - I was sure the mmap problem has been fixed, but obviously
the patch didn't go in...
Andrew, could you please queue this up for 2.6.26?
Ivan.
--
alpha: fix ALSA DMA mmap crash
Make dma_alloc_coherent respect gfp flags (__GFP_COMP is one that
matters).
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
---
arch/alpha/kernel/pci_iommu.c | 8 +++++---
include/asm-alpha/dma-mapping.h | 2 +-
include/asm-alpha/pci.h | 8 +++++++-
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 4e1c086..dd6e334 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -424,11 +424,13 @@ EXPORT_SYMBOL(pci_unmap_page);
else DMA_ADDRP is undefined. */
void *
-pci_alloc_consistent(struct pci_dev *pdev, size_t size, dma_addr_t *dma_addrp)
+__pci_alloc_consistent(struct pci_dev *pdev, size_t size,
+ dma_addr_t *dma_addrp, gfp_t gfp)
{
void *cpu_addr;
long order = get_order(size);
- gfp_t gfp = GFP_ATOMIC;
+
+ gfp &= ~GFP_DMA;
try_again:
cpu_addr = (void *)__get_free_pages(gfp, order);
@@ -458,7 +460,7 @@ try_again:
return cpu_addr;
}
-EXPORT_SYMBOL(pci_alloc_consistent);
+EXPORT_SYMBOL(__pci_alloc_consistent);
/* Free and unmap a consistent DMA buffer. CPU_ADDR and DMA_ADDR must
be values that were returned from pci_alloc_consistent. SIZE must
diff --git a/include/asm-alpha/dma-mapping.h b/include/asm-alpha/dma-mapping.h
index 75a1aff..db351d1 100644
--- a/include/asm-alpha/dma-mapping.h
+++ b/include/asm-alpha/dma-mapping.h
@@ -11,7 +11,7 @@
#define dma_unmap_single(dev, addr, size, dir) \
pci_unmap_single(alpha_gendev_to_pci(dev), addr, size, dir)
#define dma_alloc_coherent(dev, size, addr, gfp) \
- pci_alloc_consistent(alpha_gendev_to_pci(dev), size, addr)
+ __pci_alloc_consistent(alpha_gendev_to_pci(dev), size, addr, gfp)
#define dma_free_coherent(dev, size, va, addr) \
...I have applied the patch against the 2.6.24.3 kernel, and now have working sound on the newer PWS600au with mmap enabled alsa. Verified through the on board ESS1887 and via the M-Audio Revolution 7.1 sound card. (Ran out of time to also try the C-Media sound card. Also ran out of time to try it out on the other alphas I have.) The problem with the repeated sound bits playing at the end of certain sound files via the ESS1887 remains. Michael. --
I'll be trying that just a little later today, as in, sometime in the I don't have either of the two files mentioned above. As far as the alsa userland, I would think it's all "reasonably" current. I'm running Debian "Etch" fully patched/updated. I'll normally refrain from running things in the "unstable" or "experimental" categories unless something is broken in the "stable" tree that isn't getting fixed (e.g., a libc problem). Beyond that, I also tend to run the latest kernels to make sure we (the community) get an early warning if there are problems with kernel updates/changes on the Alpha architecture. Because it's a reasonably small list, here is the relevant "dpkg -l" output for alsa packages: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==================================-====================================-================================================================ ii alsa-base 1.0.13-5etch1 ALSA driver configuration files ii alsa-oss 1.0.12-1 ALSA wrapper for OSS applications ii alsa-utils 1.0.13-2 ALSA utilities ii alsaplayer-alsa 0.99.76-9 PCM player designed for ALSA (ALSA output module) ii alsaplayer-common 0.99.76-9 PCM player designed for ALSA (common files) ii alsaplayer-esd 0.99.76-9 PCM player designed for ALSA (EsounD output module) ii alsaplayer-gtk 0.99.76-9 PCM player designed for ALSA (GTK version) ii gstreamer0.10-alsa 0.10.10-4 ...
After thinking about this more, I am wondering if the appearance of the ESS1888 not working then coming right at about the 1.0.13 alsa release is an artefact of when I shifted from mainly using the PWS600au to mainly using the XP1000, and then trying out the es18xx driver at some stage, finding it works on the XP1000, but forgetting that it was on the PWS600au that it didn't work. It's in the distant past now and memory is getting hazy... Michael. --
Missed the original mssage, adding alsa-devel. I have a few dozen es18xx's cards but no Alpha's. Am compiling a 2.6.25-rc4 onto an x86 test box now. Rene. --
