Re: [Alsa-devel] Hammerfall DSP System Problems
On Tue, 10 Jun 2003, Paul Davis wrote: > >Like you I think the HDSP driver understands my firmware revision. I have > >also downgraded and upgraded my firmware without success. > > > >This whole Alsa/HDSP thing is amazingly weird... > > at the moment, i regret that we made the move to user-space loading of > the "firmware" when we did. i think now that it was a mistake to do it > at that time. it has caused a fundamental change in the way the driver > sets up, but it came at a time when we weren't confident that setup > was working for various cases. I have now joined the ranks of troubleshooting HDSP owner. I have a cardbus HDSP (rev 0b) with a Multiface. IBM Thinkpad A31. Kernel 2.4.20 LL+preemp with cardbus support in kernel. Multiface connected and powered via AC adaptor. I've been trying alsa-driver-0.9.4, and I detail my setup and problems below: snd-hammerfall-mem loads normally snd-hdspfirst stage loads fine (dmesg output snip): PCI: Setting latency timer of device 06:00.0 to 64 ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:4110: card initialization pending : waiting for firmware -- # hdsploader hdsploader - firmware loader for RME Hammerfall DSP cards Looking for HDSP + Multiface or Digiface cards : Card 0 : RME Hammerfall DSP at 0x3100, irq 9 Upload firmware for card hw:0 Hwdep ioctl error on card hw:0 : Input/output error. dmesg snippet while hdsploader ran with extra debugging added by me: ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:644: wait for FIFO status <= 0 failed after 30 iterations ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:3804: initializing firmware upload ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:522: loading firmware the code in snd_hdsp_create_alsa_devices() is executed here, successfully up until snd_hdsp_set_defaults() is called. In that function, the loop where the gains for the matrix mixer are silenced executes hdsp_write_gain 128 times, and on the next iteration the following message is thrown: ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:644: wait for FIFO status <= 127 failed after 5000 iterations causing the function to return -EIO hence the ioctl error passed back to hdsploader. Any attempts to run hdsploader again result in more errors involving FIFO timeouts, getting worse until the following message is thrown every time: ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:3804: initializing firmware upload ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:508: Hammerfall-DSP: no Digiface or Multiface connected! Unloading the modules, and ejecting and reinserting the card doesn't help matters, nor does a warm reboot. I do not have windows on the laptop (yet) so I have not attempted to get it working there (to load the multiface firmware, then warm boot) or to downgrade the hdsp firmware to 0a. Ideally, I can help to debug the primary problems with recent HDSP and recent ALSA I don't *need* to use the hardware right away (but I would like to :) If there is any offlist discussion about the HDSP debugging, please include me in those messages. D R Holsbeck, what version of ALSA, and what HDSP firmware are you successfully using on your A31? I know you have the Digiface though... I have the multiface. Paul, any info you have on the initialization steps or iobox identification would be useful. The code in hdsp_get_iobox_version() seems a bit odd to me. I always get the: ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:644: wait for FIFO status <= 0 failed after 30 iterations in the primary conditional where it picks multiface or digiface. I suppose that is intentional, but I wonder if that technique masks some other problem, even though I do have a multiface. How does that sequence work? I want to get this crap working so I can test ardour better :) jlc --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: snd-usb-audio: quirk for Edirol UA-5 in Advanced Mode
The error is as follows; I've tried to move a couple locks around but I can't figure it out. -->8 bad: scheduling while atomic! Call Trace: [] schedule+0x3a6/0x3b0 [] schedule_timeout+0x5a/0xb0 [] process_timeout+0x0/0x10 [] usb_start_wait_urb+0xaf/0x190 [usbcore] [] default_wake_function+0x0/0x30 [] usb_alloc_urb+0x2f/0x50 [usbcore] [] usb_internal_control_msg+0x67/0x80 [usbcore] [] usb_control_msg+0x8e/0xb0 [usbcore] [] usb_set_interface+0xbd/0x220 [usbcore] [] hcd_endpoint_disable+0x0/0x1c0 [usbcore] [] set_format+0xd1/0x3a0 [snd_usb_audio] [] snd_usb_pcm_prepare+0x34/0x50 [snd_usb_audio] [] snd_pcm_do_prepare+0x15/0x40 [snd_pcm] [] handle_mm_fault+0xe2/0x180 [] snd_pcm_action_single+0x34/0x60 [snd_pcm] [] snd_pcm_action_prepare+0x0/0x18 [snd_pcm] [] snd_pcm_action_lock_irq+0x96/0xa0 [snd_pcm] [] snd_pcm_action_prepare+0x0/0x18 [snd_pcm] [] snd_pcm_prepare+0x74/0x90 [snd_pcm] [] snd_pcm_action_prepare+0x0/0x18 [snd_pcm] [] snd_pcm_playback_ioctl1+0x70/0x430 [snd_pcm] [] run_timer_softirq+0x100/0x1a0 [] sys_ioctl+0x100/0x290 [] syscall_call+0x7/0xb -->8 Stephane On Tue, 10 Jun 2003, Stephane Alnet wrote: > Hi, > > (Hopefully this is the right place to post this!) > > Attached is a diff file for the Edirol UA-5 Advanced Mode against kernel > 2.5.70-bk14 sound/usb. > > I added a new QUIRK mode (QUIRK_AUDIOSTREAM_INTERFACE) which basically > forces an interface (and its altsettings) into Audio/AudioStream. When in > Advanced Mode, the UA-5 exposes all its interfaces in class 255/255 > (Vendor/Vendor), but actually besides this all the descriptors are valid > USB Audio control/interfaces/endpoints/... So this quirk simply overwrites > the streaming interfaces class/subclass with the proper values. (My > understanding is that we don't need to care about the audiocontrol > interface.) > > Recording is working properly (tested with "arecord -c 2 -f S24_3LE -r > 96000" on x86, for example); playback is crashing due to a "bad: > scheduling while atomic!" problem I haven't looked at yet. > > (Note: this change only applies to Advanced Mode, which provides access to > 24bits samples and the 96kHz sampling rates. The non-Advanced Mode of the > UA-5 works just fine with the default driver at 44.1 and 48kHz, giving > 16bits samples, as far as I can tell.) > > Feel free to integrate the diff into the current distribution/kernel as > needed. > > I'd be interested in feedback on whether this is working for other people, > and also help in troubleshooting the playback crash. > > Thank you, > Stephane --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Fwd: RE: To ESS Tech Support
Dear ALSA developers, Here is a message from ESS regarding getting some information for the ESS1988/Allegro-1 series cards in order to get better support for them in linux. I hope that some others will help me badger the ESS people in order to (A) release info needed to make the Linux driver or (B) release the Windows driver source so that it can be used for ideas for the Linux driver. If you choose to reply to this, please CC me as I am not subscribed to this list. Thanks, Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org --- Begin Message --- Sorry, we don't have Linux driver to share with you. Regards, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 2:00 AM To: [EMAIL PROTECTED] Subject:To ESS Tech Support Tech Support Contact Form --- PERSONAL INFORMATION: First Name: Warren Last Name : Turkal Country: USA Phone Number : 901-372-3416 Email Address : [EMAIL PROTECTED] ESS Chip ID : es1988 Windows Version? : Linux Product Brand & Model of PC/Notebook or Add-in Board? : Gateway 600ygr Current ESS Driver Version? : Linux 2.5.70 Contacted Product Manufacturer? : yes Updated Driver? : yes Read FAQ? : yes Did FAQ Help? : no SPECIFIC PROBLEM: Simple dsp audio i/o is supported in your es1988 under Linux, but I would like to add full support for the card. 02:03.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1 (rev 12) Subsystem: Gateway 2000: Unknown device 0600 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- --- End Message ---
Re: [Alsa-devel] Getting actual sample rate
>Anyone care to shed the light on the math for what totalmix does
>regarding fader-to-mixer, fader-to-db and mixer-to-fader values? What I
>have works, but it's UGLY. (well just the constants... I like things to
>be simple.)
you could use the settings in ardour, which has relatively
sophisticated non-linear, volumetric slider function. these map
between a 0..1 fractional position and a gain coefficient.
static inline double
gain_to_slider_position (ARDOUR::gain_t g)
{
if (g == 0) return 0;
return pow((6.0*log(g)/log(2.0)+192.0)/198.0, 8.0);
}
static inline ARDOUR::gain_t
slider_position_to_gain (double pos)
{
/* XXX Marcus writes: this doesn't seem right to me. but i don't have a better
answer ... */
return pow (2.0,(sqrt(sqrt(sqrt(pos)))*198.0-192.0)/6.0);
}
---
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Getting actual sample rate
Anyone care to shed the light on the math for what totalmix does regarding fader-to-mixer, fader-to-db and mixer-to-fader values? What I have works, but it's UGLY. (well just the constants... I like things to be simple.) d! On Wed, 2003-06-11 at 00:48, tom burkart wrote: > Today, Paul Davis wrote: > > > thomas' code contains the results of the communications i had with RME > > about this. it was unclear if the conversions should go into the > > driver or not. > I had a similar issue with a driver that is about to be published and I > decided that userspace can do that one... signature.asc Description: This is a digitally signed message part
[Alsa-devel] 0.9.4 library mem leak?
Hi all, I modified the code in amixer.c for my own use. Instead of being a command line utility that ends after every mixer access, I have it as a function call from a larger program. I also cut it down quite a bit so that I am only using sset for Master and PCM. The problem that I am running into is that after each iteration of this code, I am losing 4k of memory. When I kill my program, all memory is returned to the system, so it points towards the alsa library as being the culprit. I kept the basic initialization scheme of amixer intact in my program, which includes successive calls to snd_mixer_open, snd_mixer_attach, snd_mixer_selem_register, and snd_mixer_load. In debugging this problem, I found that the memory is lost after the call to snd_mixer_load. One would assume that snd_mixer_close would take care of all memory allocations, but it does not seem to clean it up properly. This leads me to believe that some unexpected allocation is being made in snd_mixer_load. I traced it down into the library code, and I got to a point where I commented out the ioctl call in the function snd_ctl_hw_elem_list and this seemed to remedy the problem. To go one step back, I see that this function is being accessed in a while loop in the function snd_hctl_load. Within this loop is the function snd_ctl_elem_list_alloc_space, and I looked at its code to see if anything was out of whack, but it all seemed OK. At this point, I'm running out of ideas.plus, I think I may have looked right at the problem piece of code but did not recognize it. Has anyone come across this before? Am I doing something wrong, or is the library really leaking? Can anyone out there point me in the right direction? Any and all help on this would be greatly appreciated! I can't accept the fact that amixer can only be used as a command line interface to save that 4k per access! - Chris Pechie _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Power saving mode
My card which can enter a low power state. It turns off some components but it leaves the PCI bus interface active. To bring the card back to life it has to be reinitialized from scratch. What "D" state is it ? PCI power management papers say that already in D1 state i/o space is disabled. I'm a bit confused... I can't find any doc about D0.5 :) Bye. --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Regarding ALSA-LIBRARY
On 11-Jun-2003 Sundaranathan S wrote: > Hi All, > > Can anyone tell me how to test alsa-lib APIs. If there is any > documentation available please let me know. Yes, the official documentation is here: http://www.alsa-project.org/documentation.php3 Bye. --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] problems with rme digi96/8
On Wednesday 11 June 2003 16.03, Gorm David Lai wrote: > Thanks for the advice, though it still doesn't work. > It seems to play, and sets the right sync on the mixing console. The > console just doesn't get any input. > Do I have to unmute the card anywhere? Note that my example uses /dev/zero (zero input) so it should be silent. Put something with sound in it instead of /dev/zero. No, you shouldn't need to unmute the card (if you are not using analog output), the digital output is just digital, no volume control for it exists. A classical mistake is of course to connect ADAT input to ADAT input, but I suppose you have checked that. /Anders --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Hammerfall DSP System Problems
> > so I think > > I'm almost set to be able to try this stuff out again. > > For what it's worth, i had problems with alsa 0.9.4 & SMP. i think > there are some spinlock changes that aren't very well debugged yet. > On the other hand, alsa 0.9rc7 seems fairly stable. i've gotten > some lockups, but i've also used jack for 4-5 hours without any > problem. Well, I found last night that if I removed Alsa and then rebuilt it, that as long as I didn't power down 0.9.4-rc1 stayed up and I could see my card even after a warm boot, but again, after a cold boot Alsa no longer recognized the card. So, my new strategy is that every morning, as I brew my tea, I now do: emerge -C alsa-driver alsa-utils alsa-tools ACCEPT_KEYWORDS="~x86" emerge alsa-driver alsa-utils alsa-tools and then warm boot to get the driver to find the card. I still don't get sound, but at least my CPU knows the card is there. I guess life is good when you finally know how to cope with it! ;-) Mark --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] problems with rme digi96/8
Thanks for the advice, though it still doesn't work. It seems to play, and sets the right sync on the mixing console. The console just doesn't get any input. Do I have to unmute the card anywhere? /Gorm On Wed, 2003-06-11 at 15:48, Anders Torger wrote: > > Test this: > > aplay -D hw:0,1 -r 44100 -f S16_LE -c 8 /dev/zero > > it should work. It works on my card. > > The problem in your > > aplay -D hw:0,1 -c 8 ~/cavi/sound/01/01\ Track\ \ 1.wav > > is that aplay seems to ignore your -c 8, and reads the wav header > instead, and sets it to stereo, as you can see in the aplay output, > where it cleary says that it plays in "Stereo". > > /Anders Torger > > On Wednesday 11 June 2003 15.17, Gorm David Lai wrote: > > I also have problems with aplay. Maybe this is related? > > > > The following command: > > > > aplay -D hw:0,1 -c 8 ~/cavi/sound/01/01\ Track\ \ 1.wav > > > > Which gives the following output: > > > > Playing WAVE '/users/lai/cavi/sound/01/01 Track 1.wav' : Signed 16 > > bit Little Endian, Rate 44100 Hz, Stereo > > aplay: set_params:810: Channels count non available > > > > > > /Gorm > > > > > > > > --- > > This SF.net email is sponsored by: Etnus, makers of TotalView, The > > best thread debugger on the planet. Designed with thread debugging > > features you've never dreamed of, try TotalView 6 free at > > www.etnus.com. ___ > > Alsa-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/alsa-devel > --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] problems with rme digi96/8
Test this: aplay -D hw:0,1 -r 44100 -f S16_LE -c 8 /dev/zero it should work. It works on my card. The problem in your aplay -D hw:0,1 -c 8 ~/cavi/sound/01/01\ Track\ \ 1.wav is that aplay seems to ignore your -c 8, and reads the wav header instead, and sets it to stereo, as you can see in the aplay output, where it cleary says that it plays in "Stereo". /Anders Torger On Wednesday 11 June 2003 15.17, Gorm David Lai wrote: > I also have problems with aplay. Maybe this is related? > > The following command: > > aplay -D hw:0,1 -c 8 ~/cavi/sound/01/01\ Track\ \ 1.wav > > Which gives the following output: > > Playing WAVE '/users/lai/cavi/sound/01/01 Track 1.wav' : Signed 16 > bit Little Endian, Rate 44100 Hz, Stereo > aplay: set_params:810: Channels count non available > > > /Gorm > > > > --- > This SF.net email is sponsored by: Etnus, makers of TotalView, The > best thread debugger on the planet. Designed with thread debugging > features you've never dreamed of, try TotalView 6 free at > www.etnus.com. ___ > Alsa-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/alsa-devel --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] problems with rme digi96/8
Ok. Sorry for spamming the list, but I got a hint that may point to somewhere where someone can help me. If I use aplay with plughw:0,1 as opposed to hw:0,1 aplay acts as if it is playing, but no sound reaches the digital mixing console, though it still seems to sync to the signal. This seems to be the same problem I have in my code. So maybe it is a configuration problem? /Gorm --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] problems with rme digi96/8
I also have problems with aplay. Maybe this is related? The following command: aplay -D hw:0,1 -c 8 ~/cavi/sound/01/01\ Track\ \ 1.wav Which gives the following output: Playing WAVE '/users/lai/cavi/sound/01/01 Track 1.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo aplay: set_params:810: Channels count non available /Gorm --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Oops with snd-ymfpci and ALSA 0.9.3a
Today, Clemens Ladisch wrote: > What, exactly, does "doesn't work properly" mean? It doesn't compile? > "modprobe snd-ymfpci" fails? Error messages in /var/log/messages? > "aplay something.wav" crashes? The computer explodes? Green demons > coming out of your speakers? :-) oops. Sorry about the vagueness... "aplay something.wav" causes scratchy sounds to be emitted from the speakers. tom. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] problems with rme digi96/8
On Mon, 2003-06-09 at 19:23, Martin Langer wrote: > On Fri, Jun 06, 2003 at 12:06:33PM +0200, Gorm David Lai wrote: > > On Thu, 2003-06-05 at 21:03, Martin Langer wrote: > > > On Thu, Jun 05, 2003 at 12:17:32PM +0200, Gorm David Lai wrote: > > > > > > > > We have recently bought a RME Digi96/8 card. This connects via adat to a > > > > mixing console. > > > > > > ADAT isn't well tested, so everything is possible. But a look to wiki page > > > on http://opensrc.org/alsa/index.php?page=rme96 looks not so bad. > > > > > > Are you using plughw:0,1 or hw:0,1? What's your alsa version? > > > > > Well, I test and set only legal settings on the hardware. So every > > setting I set returns success. > > > > I normally use hw:0,1, but just tried with plughw:0,1. Sadly with no > > luck. > > My legal settings do not follow those on the page. The period size seems > > to match, but my only legal buffer size is 4096. This seems to be > > contrary to the info on the page. I also use a sample size of 16. > > I read on this page: > > For using ADAT, in case of 16 bit: > - 512 frames and 8 periods ( 512*8=4096 ) > - 128 frames and 32 periods ( 128*32=4096 ) > > Why does it not match your 16bit case? Have you choosen spdif values instead? > > But the best would be a view into the hardware description, which was under > ftp://ftp.alsa-project.org/documentation/rme/ IIRC. > > > martin > > I misunderstood the buffer size, I thought it was in kb not i frames. Not I understand. Also from the documentation I read that the card has a hardware buffer size of 64KB, which matches 4096 frames in 8 channels. I have tried the hw:0,0 for spdif btw, but that doesn't work either. Now I have also tried setting some of the sw_params. I seems the value set by snd_pcm_sw_params_set_start_threshold affects things greatly. What happens is that i can fill the buffer with samples, though at some point I suddenly get an underrun, as if the entire buffer is emptied at once. The value set by snd_pcm_sw_params_set_start_threshold approximately determines how often this happens. As said earlier these problems only occur with the rme card. I looked in the cards documentation, but I am not sure what I can use most of this for, unless I want to bypass ALSA entirely. /Gorm --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Regarding ALSA-LIBRARY
Hi All, Can anyone tell me how to test alsa-lib APIs. If there is any documentation available please let me know. thanks, -Sundaranathan SIP Technologies & Exports Ltd -- "Live as if to die tomorrow. Learn as if to live forever."
Re: [Alsa-devel] Oops with snd-ymfpci and ALSA 0.9.3a
tom burkart wrote: > Today, Clemens Ladisch wrote: > > > My Toshiba Tecra (uses YMF-744B) still does not work under 0.9.4(rel) > > Is there still an oops? > Sorry, no oops, but doesn't work properly either. What, exactly, does "doesn't work properly" mean? It doesn't compile? "modprobe snd-ymfpci" fails? Error messages in /var/log/messages? "aplay something.wav" crashes? The computer explodes? Green demons coming out of your speakers? Clemens --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Bug in ALSA Yamaha YMF-754 SPDIF support
On 10 Jun 2003, Ray Heasman wrote:
> Hi,
>
> The ALSA YMF-754 SPDIF support is incomplete in a way that ensures that
> AC-3 streams can not be decoded by standards compliant receivers. Very
> forgiving receivers will render the AC-3, but they are being kind.
> According to the standard, they should mute.
>
> FYI, I am using 0.9.4 versions of everything.
>
> Here is the problem:
>
> Broadly speaking, a SPDIF stream has two places to carry control
> information: in the Channel Status Block, and within each sample word (a
> 32-bit word).
>
> For our purposes, we only care about the "Valid" bit in each sample
> word, and the "Valid/Non-Audio" bit in the Channel Status Block.
>
> For ordinary PCM data, each block must be marked as valid audio data, as
> must each sample.
>
> For IEC61937 data (such as AC-3 or DTS), each block must be marked as
> "Invalid" (ie. Non-Audio) data, AND each and every single sample word
> must be marked as "Invalid" data too.
>
> The problem is that ALSA allows you to override the Channel Status Block
> "Invalid" bit, but then marks each sample word as being valid. Compliant
> receivers ignore all "Valid"-marked samples in a IEC61937 stream.
> Similarly, they ignore all "Invalid"-marked samples in a PCM stream.
>
> Here are the tests I ran to prove this.
>
> First I ripped a few minutes of AC-3 data off a DVD, and put it in
> gits.ac3.
>
> 1) First, check the ripped stream:
>
> Expect: Expect to hear 2 channel mixed down audio.
>
> maze foo # ac3dec gits.ac3
> 5.1 Mode 48.0 KHz 384 kbps Complete Main Audio Service
> Using PCM device 'default'
>
> Result:
>
> Normal (mixed down 2-channel) audio is heard. The stream is proven good.
> The stream is playing through a Sony AVR, using the SPDIF port, so we
> know the SPDIF port is working too, at least in 48KHz PCM mode.
>
> 2) Next, attempt to play the ripped stream as a raw SPDIF stream.
>
> Expect: Expect to hear 5.1 sound in all its glory.
>
> maze foo # ac3dec -C gits.ac3
> Using PCM device 'plug:iec958:{AES0 0x2 AES1 0x82 AES2 0x0 AES3 0x2}'
> AC3 Stream 48.0 KHz 384 kbps
>
> Result:
>
> Ok. The AVR is not happy. It indicates the presence of a stream, but
> refuses to recognise it. The stream is neither PCM nor anything else,
> according to the AVR.
>
> 3) Play the stream again, but override the Channel Status Valid bit,
> telling the receiver that it is being sent PCM data.
>
> Expect: Expect to hear nothing, as each sample should be marked
> "Invalid". Output should mute.
>
> maze foo # ac3dec -C gits.ac3 -D'plug:iec958:{AES0 0x00 AES1 0x82 AES2
> 0x0 AES3 0x2}'Using PCM device 'plug:iec958:{AES0 0x00 AES1 0x82 AES2
> 0x0 AES3 0x2}'
> AC3 Stream 48.0 KHz 384 kbps
>
> Result: compressed data rendered as if it were PCM. The receiver reports a 48kHz
> PCM signal>
>
> This shows the problem: If I tell the AVR the Channel is valid, but each
> sample is set to "Invalid", it will ignore the invalid samples. It plays
> the samples, thus the samples are being marked as valid.
>
> CONCLUSION:
>
> Sample words in IEC61937 streams are being marked "Valid". This is
> wrong.
>
> --
>
> I started looking through the code for the YMF drivers, but I am
> horribly lost. Is this easy to fix?
No. The YMF754 datasheet does not contain information how to handle the
validity bit in subframes. Also, the a_52.pdf (AC3 standard description -
can be downloaded from www.dolby.com or at ALSA FTP site) says that the
interpretation of this bit is optional:
=
4.3 Validity flag
The validity flag in time slot 28 may be used to indicate individual
16-bit words of data which are thought to be in error. If the data source
believes a particular 16-bit word contained in a sub-frame contains an
error, the validity bit may be set to 1 . Otherwise this bit shall be set
to a 0 which indicates valid data. The use of this bit by receivers is
optional.
==
I am not sure if ymfpci driver is not broken for raw S/PDIF now, but last
time I tried the code, it worked well with Sony receiver.
Jaroslav
-
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Oops with snd-ymfpci and ALSA 0.9.3a
Today, Clemens Ladisch wrote: > > My Toshiba Tecra (uses YMF-744B) still does not work under 0.9.4(rel) > Is there still an oops? Sorry, no oops, but doesn't work properly either. tom. Consultant AUSSECPhone: 61 4 1768 2202 339 Blaxland Rd., Ryde NSW 2112 Email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
