Re: HEADSUP: pca driver being retired.
It's also handy if you don't have external speakers hooked up to a machine, and want something better than beeps. Would it be a useful exercise for the minority(?) of users who use this driver to either see if it can be effectively newbussed or turned into a port or both? i'd quite like to see it reimplemented as a pcm driver; it's been on the todo list for years and should be quite simple. pca at present supports a very limited subset of the oss interface, where as a pcm driver it would behave the same as any other sound device. -cg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Need ALSA [was: Re: MIDI on SB Live! ?]
Having a port of ALSA would sure round out 5.2 nicely, and would get you MIDI support: http://www.alsa-project.org/ I think you wouldn't really do anyone a favour, including the ALSA folks, if you went and made a port right now. The ALSA project is still not at 1.00 status and still quite in-flux. One could go either way with this. Leave it for after 1.0, or grab it now and help build it up for a better 2.0. Or I guess we could initiate the ABSDSA and have support for both ALSA and OSS. Wouldn't this be even more work though? porting alsa would gain very little and be a huge regression. This can easily happen if we get behind a developer. ALSA has been sponsored by SuSE for the benefit of Linux, and there's no reason we can't pull together our resources to do the same for our OS. I'm sure someone will step forward to do the port if we have the cash for them to comfortably sit in front of their computer until the port is complete. I'd appreciate sponsoring somebody to work on our existing newpcm stuff and add the missing bits and pieces much more. Donating hardware (soundcards and MIDI-devices) would probably help very much already. OSS is on the outs. New applications that are ALSA only will soon be common, won't they? Newpcm is what, five years old? Whatever it is, it ain't new anymore. Of course, maybe I'm completely mistaken about the whole situation and all newpcm needs is a boost. you are completely mistaken. first, let me correct some of the factual inaccuracies that you are propounding: * newpcm is not even 4 years old yet. * alsa is in no way desireable- it is not a device abstraction system. every app must do userland resampling to play, say 44.1khz sound on a 48khz only chipset. given that it does not provide hardware abstraction, alsa's kernel components are far too complex. * alsa drivers are difficult to write- compare one to its corresponding newpcm driver. * newpcm has a much more advanced architecture than alsa, and is entirely different than oss. the fact that newpcm's dsp and mixer layers implement the oss api is incidental. newpcm v2, which may gain a better name, is under development. i originally hoped to have it ready for 5.0, but very poor health over the last year prevented this. instead, it will be targetted at 6.0 and probably backported to ~5.3+ once feature complete and demonstrably stable. i will not elaborate here on the features planned for v2, but replacing the api is one of them, although oss compatibility will be provided. there are a few people out there who know the plans, but they all know that i want them kept under wraps for now. with only two main developers, you should not expect v2 to be committed much before the end of this year. additional manpower would help, but don't volunteer if i'm going to have to spend time teaching you c, the kernel, kobj or the current design of newpcm. someone well versed in dsp techniques and acquainted with the mathematics of accoustics would be very helpful. money and/or hardware would be nice, but i at least am limited in speed by my body and nothing short of a few million dollars is likely to change that. the single greatest incentive to continue that the community could provide is to refrain from suggesting that newpcm be scrapped or replaced, especially by proponents who are not willing to do the code themselves, do not have a replacement working prior to their proposal, and/or have little to zero knowledge of sound hardware and the requirements of a top-flight audio infrastructure. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic during ata_resume (sound)
_mtx_lock_flags() at _mtx_lock_flags+0x43 mixer_reinit() at ds_ps_resume() bus_generic_resume() bus_generic_resume() bus_generic_resume() bus_generic_resume() bus_generic_resume() apm_resume() apm_processevent() apm_do_suspend() apm_timeout() softclock() ithread_loop() fork_exit() fork_trampoline() it would be helpful to have more information- dmesg, pcm static/preloaded kld/postboot kld, and if postboot, what else was the machine doing immediately prior to and during kldloading. also, had you used the mixer at all? -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acquiring duplicate lock of same type: "pcm channel"
--On 01 December 2002 10:26 +0100 Marc Recht <[EMAIL PROTECTED]> wrote: Hi! I'm seeing this lately: acquiring duplicate lock of same type: "pcm channel" 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 please test the patch at: http://people.freebsd.org/~cg/mixer+duplicate.diff.gz -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/dev/sound/pcm buffer.c channel.c feeder.cfeeder_fmt.c feeder_rate.c sndstat.c sound.c sound.h vchan.c
I have no idea why, but this commit broke kernel building: cc -c -O -pipe -mcpu=athlon -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/sound/isa/ad1816.c cc1: warnings being treated as errors /usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_lock': /usr/src/sys/dev/sound/isa/ad1816.c:81: warning: dereferencing `void *' pointer /usr/src/sys/dev/sound/isa/ad1816.c:81: request for member `mtx_lock' in something not a structure or union /usr/src/sys/dev/sound/isa/ad1816.c: In function `ad1816_unlock': /usr/src/sys/dev/sound/isa/ad1816.c:87: warning: dereferencing `void *' pointer /usr/src/sys/dev/sound/isa/ad1816.c:87: request for member `mtx_lock' in something not a structure or union *** Error code 1 And the same result for other consumers of snd_mtx* . i'm unable to reproduce this. have you tried a clean build? -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: multiple audio devices and /dev/dsp*
> on -CURRENT though /dev/dsp seems to be conjured up by the devfs system > and i have simply been unable to find a way to make it point my prefered > device node ... in my case /dev/dsp1. > > Am i missing something obvious here ... or is it simply not possible on > -CURRENT to do something similair to -STABLE ? sysctl hw.snd.unit= where is the unit to use by default. this can also be set from the loader. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal with pcm..
> and the sound cracks/stops playing for the fraction of a second. seems > like it happens more often during disk or network activity ( i mount > /usr/ports via nfs, and when i build a port it happens all the time). the > soundcard is a sblive. i searched the archive for this problem, but didnt > find anything, so i thought i report it. would be cool if someone has a > fix for that. known issue, will be fixed sometime soon. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: adding athlon xp to bsd.cpu.mk
> > from what i can see, identcpu.c fetches the cpu name using a cpuid
> > instruction.
>
> The part cpuid gives you is "AuthenticAMD".
> The fancy name is determined by switching on the Id.
read identcpu.c. you are correct for k6 and lesser processors. the code in
question is around line 323:
do_cpuid(0x8000, regs);
nreg = regs[0];
if (nreg >= 0x8004) {
do_cpuid(0x8002, regs);
memcpy(cpu_model, regs, sizeof regs);
do_cpuid(0x8003, regs);
memcpy(cpu_model+16, regs, sizeof regs);
do_cpuid(0x8004, regs);
memcpy(cpu_model+32, regs, sizeof regs);
}
-cg
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: adding athlon xp to bsd.cpu.mk
> What about new Durons based on the Palomino core? The problem is > that as far as I know they have nothing in their name (like XP in > Athlon's case) that distinguishes them from older Durons based on > the Thunderbird core, while they do support SSE in addition to > 3DNow and MMX. Perhaps it would be better to introduce new variable > CPUCORE, so the user could use something like the following: from what i can see, identcpu.c fetches the cpu name using a cpuid instruction. my system with dual 1.1ghz durons identifies as: CPU: AMD Duron(tm) MP Processor (1110.94-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x670 Stepping = 0 Features=0x383fbff AMD Features=0xc044<,AMIE,DSP,3DNow!> the entire "AMD Duron(tm) MP Processor" string appears to originate from the cpu, so i would suggest that the processor is named duron mp. the ident string does not change when booting a non-smp kernel, so unless the cpu is detecting the chipset as dual cpu or the bios is reprogramming the cpu, that is actually what amd have named the 1.0+ghz durons. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: " Making DMA buffer resizeable depending on audio speed/format "
> > The sound driver interface provides the application writer the choice to set > > the buffering they require. This patch has obvious implications for the > > ordering of ioctl's that we may not want to introduce. > > Yes, OSS interface allows for that, but currently FreeBSD doesn't fully > provide applications with means to control buffering, because it only > allows application to regulate front buffer size and state, while retains > back buffer (i.e. DMA buffer) out of application's control, thus > significantly lowering its ability to control audio latency. we set the hardware buffer to the smaller of the application requested size and the maximum size supported by the hardware driver. > Not actually. If our pcm driver was correctly reporting its internal state > then SDL would be able to cope with situation intelligently (it has the code to > do so), but as long as now pcm driver doesn't reports to the application state > of its DMA buffers the application has no ways to regulate buffering > intelligently. You may want to look for my previous messages on topic (more > than a year ago on multimedia@ list). I reduced this problem by downsizing > a mss buffer size from the 64KB (sic!) to 4KB now, but this creates another > problem with the high speed audio. :(( have you tested this in the last 6 months? note that mss.c does not fully implement setblocksize. some drivers do not attempt to implement it at all, but the majority implement it correctly. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sound doesn't work with acpi?
> pcm0: unable to map register space > pci1: at device 0.1 (no driver attached) my guess is that this is an intel 443mx chipset. that message, "unable to map register space" is not generated by the ich/443mx driver, so i doubt it's actually a sound issue. in other words, prod mike until he fixes it. :) -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: trying to play sound in -current
> I suppose it "uses" it, but why does it lock it for extended periods of > time. KDE can't even use the sound driver while this is happening. set sysctl hw.snd.verbose as high as it'll go (3, with the latest code) and cat /dev/sndstat. it'll tell you the pid of the process using each channel. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current & /dev/dsp: device busy
> Same here, but with an SB64 PCI (chipset ES1370). So it's not limited > to SB16 cards. fixed in sys/dev/sound/pcm/sound.c rev 1.56, just committed. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCM sound problems in -current ??
> I'm having problems with both an internal VIA'686 and a PCI base > ESS Solo1, both seem to loose interrupts. The interrupts doesn't > even show up in a vmstat -i / systat so something is definitly > wrong. BTW the exact same HW work just fine with -stable ? while i've not tested either of these chips for a while (lack of slots, anyone know of a motherboard with ~20 pci and ~10 isa slots?) i can't think of any changes that might cause this except possibly the introduction of INTR_TYPE_AV - and then only if you're using modules and your modules are built from newer source than your kernel. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sound driver breakage/megapatch
> Oh, sorry - yes, I can... I watched the pcm interrupt (irq 9 on my box) > increment using vmstat -i. I had seen something in the archives about that > not happening. is there any other device using irq 9? -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sound driver breakage/megapatch
> Apr 19 15:09:31 zorba /boot/kernel/kernel: pcm0: play interrupt timeout, channel dead > Apr 19 15:19:00 zorba /boot/kernel/kernel: pcm0: play interrupt timeout, channel dead can anyone suffering from this problem confirm that the hardware is generating interrupts? use 'systat -vm 1' to watch while you try to play sound. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic within sound driver
> Stopped at _mtx_lock_sleep+0x2e2: movb 0x1d5(%edx),%al > _mtx_lock_sleep > snd_mtxlock > ad1816_lock fix just committed, sys/dev/sound/isa/ad1816.c rev 1.18. you must be the only freebsd user on the planet with an ad1816. :) -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: resource_list_alloc
> just upgraded my tree and did a reinstall ... trace is: > > resource_list_alloc(c0d9eec0,c0d90180,c0d99b80,4,c0d4a30c) at resource_list_alloc+0xd3 > isa_alloc_resource() @ +0xd0 > bus_alloc_resource() @ +0x5f > opti_detect @ +0x99 > mss_detect @ +0x52 > mss_probe @ +0x30a > device_probe_child @ +0xca > device_probe_and_attach @ +0x41 > isa_probe_children @ +0xde > configure @ +0x32 > mi_startup @ +0x6e > begin @ +0x29 can you try http://people.freebsd.org/~cg/mssfix.diff.gz ? -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How could I do with my sound card?
> says: pcm1: at port > 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on > isa0 you have a bogus device pcm0. you probably have a mistake in your hints file. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: modified ich sound driver for current?
> Mixer stuff was modified couple days ago. Does anyone have working > ich driver? I got original driver from more than that, a couple of weeks would be closer. > http://www.katsurajima.seya.yokohama.jp/ich/index.en.html but now this > site is dead. Does author (Katsurajima Naoto) of this driver read > FreeBSD mailing lists? Could someone include this driver to current > so it get updated? i'm not happy with some of the things the driver does, so until i can modify it i won't commit it. this necessitates having hardware to test with, which i should be getting in the near future. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Soundblaster 64 PCI
> > If this is a known problem, I'll stop for now and watch out for fixes. > > If it's not the expected behaviour from the PCM driver though, can > > anyone advise? > > Okay, just checked and it appears tha htis is the same error that I'm > seeing on mine, as reported yesterday ... not sure if its known or not, > but its not "just you" ... are either of you using esound or xmms? if so, i know the cause of this and it will be fixed shortly, once my primary development box recovers from killing its cpu. if not, i'll try to reproduce this. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newpcm audio recording
> I have a SB32 isa-card. what revision of sys/dev/sound/isa/sb16.c ? -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newpcm/kobj
> in the near future, i intend to commit my kobjified newpcm. this gives us > several benefits, including: > > * easier extensibility- new optional methods can be added to > ac97/mixer/channel classes without having to fixup every driver. > > * forward compatibility for drivers, provided no new mandatory methods are > added. > > however, all drivers not in the tree at this time will need to be updated. > > i hope to mfc to -stable in approximately one month, along with the kobj > system. newbus in -stable will not be kobjified. the diff for newpcm/kobj is at http://people.freebsd.org/~cg/kobj.diff.gz -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
newpcm/kobj
in the near future, i intend to commit my kobjified newpcm. this gives us several benefits, including: * easier extensibility- new optional methods can be added to ac97/mixer/channel classes without having to fixup every driver. * forward compatibility for drivers, provided no new mandatory methods are added. however, all drivers not in the tree at this time will need to be updated. i hope to mfc to -stable in approximately one month, along with the kobj system. newbus in -stable will not be kobjified. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: -current on ibm tp a20p?
> the sound card is a Crystal Semiconductor CS 4624 controller with CS 4297A > AC97 codec, pcic0 is a TI PCI-1450 PCI-CardBus Bridge. > > sound output results in "pcm0: play interrupt timeout, channel dead". try turning off apm and all power saving in the bios setup. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Mixer weirdness (SB 64 AWE)
> Now the volume states are often wedged when the machine boots up, eg only > one channel is used of the two, or the volume level is > drastically different > on the two channels. The best part is, mixer(8) does not show any of this, > and setting it to different values does not seem to influence the > volume. Eg > setting 'mixer vol 0:0' still does not mute sound. should be fixed now (sys/dev/sound/isa/sb16.c rev 1.61) -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: SB128/ES1370 sound broken since 26th Oct
> SB128 sound support has been broken over a week now. I don't who has > made changes on 26th Oct but after these changes I can't get any sound > out of my machine. Sources cvsupped 25th Oct still worked fine. should be fixed now. (sys/dev/sound/pci/es137x.c rev 1.25) -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A few issues I ran into (and a quick question)
> First of all (using -current of 26 October) I was not able to attach pcm to > my Yamaha OPL-SAx soundcard in my Toshiba Tecra8000 when using snd_pcm.ko. > Using a statically compiled driver though I had no trouble whatsoever. The > module was pre-loaded at boot time. snd_pcm is the core module, it requires other driver modules before it will be activated. currently, loading snd_driver will load all drivers and the core, but this will change. > 2nd with a working pcm driver I get sound glitches with display activity > under X (4.0). This was something I had before with both pcm and OSS's > sounddriver so it's not really an issue with the pcm driver but with the > X-server I assume. I DO have additional glitches occaisionally, that I > didn't have before and they are accompanied by the following kernel message: this is an artifact of the smpng work increasing irq latency. it will go away in time. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mixer no longer works
> > In -CURRENT cvsupped as of today, the mixer no longer works. anything that > > tries to access the mixer just says "Operation not permitted" > > using devfs? i just committed a fix; devfs was not the problem. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mixer no longer works
> In -CURRENT cvsupped as of today, the mixer no longer works. anything that > tries to access the mixer just says "Operation not permitted" using devfs? -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Neomagic] newpcm problems under current
> According to Cameron Grant: > > this is a known problem. it seems the neomagic driver never worked right, > Well, it used to work :) it used to *appear* to work. > > so when newpcm became dependant on interrupts it ceased functioning. now we > > trap the lack of irqs and disable the channel and emit a warning to the > > console. > I do get lots of interrupt. I patched my kernel in June to generate a printf > for each interrupt and I was seeing lots of them without even running mpg123. is the irq shared? have your printf display the neomagic status - i'll bet it's 0 indicating the irq was not generated by the neomagic. > > access to hardware would make this easier to fix. > > I would be difficult to send you my laptop, I do use it :-) :) -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Neomagic] newpcm problems under current
> The first time I run mpg123, it does nothing (that is, no sound is emitted) > and afterwards, /dev/dsp can't be opened at all... > Any idea ? this is a known problem. it seems the neomagic driver never worked right, so when newpcm became dependant on interrupts it ceased functioning. now we trap the lack of irqs and disable the channel and emit a warning to the console. access to hardware would make this easier to fix. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: no audio with newpcm driver on TP600E
> # For PnP/PCI sound cards > #device pcm > #device sbc > #device csa > > # For non-PnP cards: > device pcm0 at isa? irq 10 drq 1 flags 0x0 > device sbc0 at isa? port 0x220 irq 5 drq 1 flags 0x15 > device csa > device gusc0 at isa? port 0x220 irq 5 drq 1 flags 0x13 this is wrong. try: options PNPBIOS device pcm - cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm
> Just to let someone know, my ViBRA16X is still having the problem with > static. i've replicated it, but have no idea of the cause. i'll probably rework the sb driver when i rip it and the ess driver apart, but that will wait until i get an ess card. - cameron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
newpcm
would everyone who currently has an issue outstanding with newpcm please report it to me in the next few days directly, please, so i can get an idea of what needs work before release. i need as much detail as possible. - cameron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
neomagic 256av/256zx audio
i have just committed a driver for the neomagic chips. please test and post results. - cameron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: isa_dmastart: bad bounce buffer
> bus_dmamap_load: Too many segs! buf_len = 0xdf00 > bus_dmamap_load: Too many segs! buf_len = 0xdf00 argh, forgot something. try mss.c rev 1.44, sb.c rev 1.48. - cameron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: isa_dmastart: bad bounce buffer
the panics should be fixed now with sb.c rev 1.47, mss.c rev 1.43. - cameron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Newpcm is broken again for mpg123 (ESS 1868 isa sound card)
> Donn> "ba ba ba ba ba ba ba ba ba ba ba ba ba ba". I have the ESS > Donn> 1868, of course. Well, I (wisely) saved my old kernel as > Donn> /kernel.good and just booted into that. > > Donn> Could you also say what was fixed if you get around to it? I'd > Donn> to learn a little more about the sound driver. > The following things were in the recent mail of mine: > > - All ioctl(2)s go to see the secondary buffer(if I have forget nothing). > - chn_setblocksize() changes the size of the secondary buffer. > - chn_mmap() maps the secondary buffer. > - chn_poll() invokes DMA. > - chn_wrintr() performs DMA emulation for pcm devices with no DMA > functionality(requested by nyan). > - SNDCTL_DSP_SETFRAGMENT handles the count correctly. > - GETI/OSPACE returns the number of fragments. > - DMA transfer keeps running upon underrun. Some DSPs seem to end up > with an unpredictable result if the DMA gets stopped followed by > immediate restart. This revokes the change in sys/dev/sound/pcm/channel.c > rev 1.12. > - chn_write() and chn_read() returns EAGAIN for nonblocking if there > are no space to write or data to read. the ess problem was a result of me reducing the buffer size to 8k instead of 64k to see what would happen. only ess cards seem to have problems, so it's back to 64k for them but 8k for other isa cards. - cameron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mic cannot be deactivated
> I've got a ESS1879 as well. Try the following patch, Cameron sent me. i commited an equivalent fix this morning. - cameron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ESS 1868, newpcm, and Linux RealPlayer 5.0
> On Sat, 18 Dec 1999, Donn Miller wrote: > > > I just rebuilt my kernel from a recent cvsup. Of course, I have > > > > device pcm0 > > device sbc0 > > > > in my kernel config file. When I try to play a realaudio clip > > with Linux rvplayer (RealPlayer 5.0), rvplayer downloads the > > clip, and instead of playing the clip, rvplayer just hangs until > > I kill it. Is the ESS 1868 isa card working with sbc0 and pcm0? > > Anyone else have this problem with rvplayer? I tried the OSS > > driver modules, and the same rvplayer works OK there. > > The ESS 18xx support seems to be broken at the moment. I have one here and > I'll fix it as soon as I get a chance to work on it. a recent commit changed the assumptions made by the upper layer code, breaking devices not using auto-init dma. last night i committed a fix to make the ess cards use autoinit, so they should work now. - cameron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newpcm
Doug Rabson wrote: > > Unfortunately I can't get it working on my SB16PNP with previously worked > > flamessly with "oldpcm". I've did as you suggested - as it seems to be pnp card > > I've removed all "at isa0 ", rebuilded and rebooted. But with the new > > kernel I've observed 2 things: (1) my "pnp 1 0 os enable ..." string is no > > longer recognised; (2) SB is no longer works :-(. Following is relevant pieces > > of my dmesg output for both cases: > > Could you send the output of pnpinfo. We are probably missing an ID in the > driver. The new pnp code doesn't need the "pnp 1 0 ..." stuff as it deals > with resource allocation itself without the need for user intervention. this is the second such report i've had; in the previous case the pnp id was present, so i guess there is a problem elsewhere. - cameron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
newpcm
apologies for this message being late. newpcm has now been committed in -current, with functional trident 4dwave, es1370, sb and mss support. minimal changes to kernel config should be required: pci devices: device pcm0 isa pnp devices: controller pnp0 device pcm0 non-pnp isa devices: device pcm0 at ..., as before newpcm should work on any freebsd-supported platform as it uses newbus. it has been tested on i386 and alpha. there should be no change to the userland interface other than addition of mmap()/trigger support, which has been tested with an oss sample program, but no real applications. a design overview of newpcm is available at http://www.vilnya.demon.co.uk/design.txt i intend to put a hardware driver skeleton up on the same site in the next few days. - cameron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
it's time...
to let newpcm out of the cage so you can all get your grubby little hands on it. http://www.vilnya.demon.co.uk/newpcm+dfrpnp-19990807.diff.gz this is a patch against a recent -current. if you have a pci or isapnp soundcard, you should have pnp0 and pcm0 in your kernel config as appropriate. isapnp cards should not need any pnp lines in kernel.conf. the list of supported cards is as for luigi's driver, with the addition of a couple more mss-clones, and trident 4dwave. there is a part done aureal vortex driver which is as yet nonfunctional. mmap() is supported but not well tested. format conversions are supported. the code seems to be stable. please test it and email me success and failure reports. - cameron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
