- Alsa-devel - mailman.alsa-project.org

[alsa-devel] usb midi disconnect -> kernel oops
by Dmitry Baikov 04 Apr '07

04 Apr '07

Hi! If I have a running application which connects (via alsa seq) to usb midi device, and device is disconnected, I get a kernel oops. kernels tried: 2.6.20-rt8 (in-kernel alsa), 2.6.21-rc5-rt3 (in-kernel alsa, and 1.0.14_rc3) Kernel dump attached. Dmitry.

3 11

Re: [alsa-devel] SPDIF/IEC958 sample rate on HDA/ALC882
by Dag Lem 03 Apr '07

03 Apr '07

Takashi Iwai <tiwai <at> suse.de> writes: > > Hi, > > Sorry, looks like I overlooked this post... > > At Wed, 01 Nov 2006 17:58:55 +0100, > Erik Slagter wrote: > > > > Sorry if this is considered to be "user" question, but I got no response > > at all from the "user" list. Guess the real cracks hang around here. > > > > I have lots of questions I cannot resolve from all of the docs, but for > > the moment I'll stick to the most important one. > > > > The combination of HDA/ALC882 should be able to deliver sound at 96 kHz > > (hda..., right...) Also the ALC882 datasheet says it can deliver sound > > at 96 kHz. > > > > In practise, though, I cannot get it to output any other sample rate > > than 48 kHz. Any other sample rate handed to hw:0,0 is simply converted > > (somewhere??? and badly...) to 48 kHz and the SPDIF is still driven at > > 48 kHz. > > > > iecset allows me to set the rate to 32/44.1/48 kHz, the spdif output is > > still at 48 kHz. Some other flags from iecset are actually honoured > > (like "data" and "emphasis"). > > It's simply because iecset program doesn't support the rates over > 48kHz. But the hda-intel driver supports the rate, AFAIK. > (At least, there is no particular code that restricts over-48kHz.) > > One thing to be noted is that if you use "hw" PCM device, you have to > set up the SPDIF status bits _manually_ via control API. If you use > "iec958" or "spdif" PCM device, you can pass these bits as optional > arguments at opening the PCM. > > > I can ask aplay to play at various rates (from a suitable PCM file), but > > it complains at any other rate than 44.1 or 48 (notably 32) kHz that the > > rate is not supported. It plays at 44.1 kHz though. And again converts > > it to 48 kHz! Sigh... > > Who complains? At least, the driver won't. > > > Maybe I am using the wrong "hw", there is also a "hw:0,2" device, which > > I cannot make work properly at all (only one channel is output, large > > chunks are discarded, much much clipping). > > The first PCM device is for the multi-output PCM. It's for both > analog and digital. The dedicated SPDIF is the secondary one. > > Takashi > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > Hi, I was googling around and found this (old) post; I can confirm that there are severe problems with the ALC882 and/or the driver code. I'm experiencing the same problem as Erik - I cannot get the ALC882 to transmit at any other sample rate than 48kHz over S/PDIF. When I attempt to play 44.1kHz sound, the S/PDIF connection is still locked at 48kHz (shown by my amplifier), and the resulting sound is less than pleasing. It would seem like a 44.1kHz signal packed in a 48kHz frame rate played back directly - high-pitched sounds suffer badly from what my ears recognize as straightforward sample picking as opposed to resampling. Looking at hda_codec.c:convert_from_spdif_status() it seems that the IEC958 parameter bit for 44.1kHz/48kHz is not used for anything (correct me if I'm wrong). This would mean that the rate is only set in snd_hda_codec_setup_stream(), and as far as I can tell from looking at the array rate_bits and the ALC882 Series Datasheet the setting is correct for 44.1kHz. Since I can't find any obvious mistake in the HDA code, I guess there is some problem in patch_realtek.c, or an initialization incompatibility with the HDA code and the ALC882 chip. There are certainly initialization problems somewhere, as the S/PDIF output is sometimes not able to send AC3 data correctly (amplifier cannot detect AC3 and stays silent), and attempting to play audio (even 48kHz) results in intermittent screeches. This is solved by setting and resetting the IEC958 control widget, trying again and again until it finally works. When it does work, it works without a hitch until the next reboot. Any ideas? Is there anything I can help to test in order to nail down the problem? My motherboard is an Asus P5W DH Deluxe with an 82801G HDA controller, in case this has any relevance. -- Best regards, Dag Lem

4 20

[alsa-devel] Vanilla Blocked I/O probs
by Gordon Miller 03 Apr '07

03 Apr '07

Hi, I am calling rc = snd_pcm_readi (handle, buffer, MAX_LEN) but rc is always 4 short of MAX_LEN (1020 instead of 1024). I thought that it would just block until MAX_LEN frames were available. This is really doing my head in, and any help would be appreciated. Cheers

3 4

Re: [alsa-devel] Alsa OSS - who is maintaining it?
by Takashi Iwai 03 Apr '07

03 Apr '07

At Tue, 03 Apr 2007 00:35:21 +0200, Stefan de Konink wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Takashi Iwai wrote: > > At Wed, 28 Mar 2007 13:08:09 +0200 (CEST), > > Stefan de Konink wrote: > >> On Wed, 28 Mar 2007, Takashi Iwai wrote: > >> > >>> Did you try other drivers, such as usb-audio? > >> I did not. > > > > Then try it if you have one. > > Don't have one. It's a pity. > >>> And, you're using user-space alsa-oss wrapper (e.g. via aoss wrapper), > >>> right? The user-space emulation and kernel-space emulation are > >>> totally different, so I have to know what you actually tried. > >> I'm only using the in kernel translation. > > > > Then try aoss, too. > > aoss program gives the the same garbage. Hm, then I suspect rather it's a problem in the aoa driver side. To make sure, check /proc/asound/card0/pcm0p/sub0/hw_params has no "OSS" entry when you're playing via aoss. If a line like "OSS Format" appears there, it is still kernel oss-emulation. After you confirm it's a native ALSA in the driver execution, compare the parameters there between the working status (using ALSA API) and non-working status (OSS API). Takashi

1 0

[alsa-devel] USB audio class v2.0
by Daniel Mack 03 Apr '07

03 Apr '07

Hi, is there any efford taken to support devices conforming to the USB audio class in version 2.0? I'm just curious if anybody ever started work on that since I couldn't find any hint in the sources. Greets, Daniel

3 4

[alsa-devel] dereferencing pointer error in app but not in lib
by intellij 03 Apr '07

03 Apr '07

In the library, like pcm.c I can code like const char *snd_pcm_name(snd_pcm_t pcm) { return pcm->name; } At the same time, the same code in the application causes "dereferencing pointer to incomplete type" error. Note, the compiler does not tell that there is no such field in the pcm structure. It just thinks that the name has another type. Which one? thank you.

2 1

[alsa-devel] PCM low level - need help
by ODINOT Jean-Marc ETRALI 02 Apr '07

02 Apr '07

Hi Alsa gurus, I've to write an alsa driver for a custom card. I readed "writing an alsa driver" and other paper about alsa and drivers. Well I got a result, but not as good as I think it's possible with alsa. My card have 30 output slots (and 7 input slots), can be 8Khz or 16Khz (same rate for every slots), 16bits little endian by sample, can have one or more sample for each slot (same for every slots) in a frame, an hardware IT every frame (a frame is 30 slots :-). The purpose is to get, for each IT, a frame with all the datas. IT -> frame [channel1][channel2][channel3]...[channel30] channelX [sample1][sample2]...[sampleN] sampleX [16bitsle] At this time, I've something like a frame if I use channel30 with speaker-test -c30, but if I use channel1, alsa give me a buffer with many samples for channel1. And, just after oppening, I get an extra word. BTW I use .copy to get the buffer. My questions: -why the extra word (can I avoid it?)? -how set the buffer len to always have all my channels (used or not)? -is it possible to have more than a sample by channel contiguous? Think's it's all for today, but maybe your answers will give me more ideas :-) Thanx for replies (and please, forgive my awful english :-(, JM ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ********************************

2 1

Re: [alsa-devel] [Alsa-devel] [i8x0] docking station audio-out ceased to work
by Takashi Iwai 02 Apr '07

02 Apr '07

At Wed, 21 Mar 2007 23:57:32 +0100, Andreas Happe wrote: > > On Mon, 2007-03-19 at 18:53 +0100, Takashi Iwai wrote: > > Interesting. Usually AC97-SPSA specifies the AC97 slot for SPDIF > > output. The full (= 3) means the slot 10/11, 0 means slot 3/4. > > IIUC, AC97-SPSA must be 3 for docking station output working? > > If i remember correctly - but I was on holiday before the hardware > stopped to work (it was either set to 0 or 3, but I think that it was > 3). > > > If yes, try to set spdif_aclink=1 with the latest driver (HG > > version)... > > do you mean alsa-driver or alsa-kernel? I'm somehow reluctant to replace > my distribution's userspace utilities with self-compiled stuff (while i > would happily build a custom kernel). You need both trees to compile the driver. > BTW: a short link to a tutorial howto build hg kernels (or against what > kernel release). I checked it out, copied over the sound/ directory and > rebuild my 2.6.21-rc4 kernel. Copying to Linus kernel may work in most cases but sometimes not since alsa-kernel repo is updated for mm tree. The building HG driver is easy. Clone (both) repos, and run hgcompile script instead of configure. See alsa-driver/INSTALL. Takashi

2 10

[alsa-devel] how does hw:0, 1 eventually get mapped to /dev/snd/controlC0 and company? is this on the wiki somewhere?
by John Utz 02 Apr '07

02 Apr '07

how does this work? an explicit explanation would be great, but i'd even settle for a vague handwavy one at this point.

3 9

[alsa-devel] usleep() and nanosleep() timings seem inaccurate using ALSA
by Carlo Florendo 31 Mar '07

31 Mar '07

Good Day! After studying the intricacies of MIDI, I ended up writing an implementation of the MIDI protocol and file format. I then studied the ALSA sequencer API to be able to control a synthesizer keyboard and play MIDI files. I've used aplaymidi, aconnect, arecordmidi, and all those great ALSA utilities. They're very good! However, I wanted to have a simple ncurses based, command line MIDI sequencer meant for small Linux distributions such as DSL or Trustix so I began to write a command line sequencer using ALSA. I've encountered one problem about using usleep() and nanosleep() especially in 2.4 kernels. The core of my problem in my application is that the MIDI files slow down their tempo when pitch changes are made on a particular channel/track, while a NOTE-ON event is being played. For simplicity's sake, I'll give timing examples in terms of seconds and not bars nor measures. For example, if I've got a 2 second NOTE-ON playing a guitar note, all timings are ok. If the NOTE-ON is interspersed with CONTROLLER messages such as a pitch bend, the part which is supposed to sound in approximately 2 seconds, sounds much longer than that. The effect of this is that a ritardando is heard everytime short-duration CONTROLLER messages are sent. The problem disappears when I use the sequencer queues. However, the problem manifests itself when using direct output (i.e. not using queues, using snd_seq_event_output and snd_seq_drain_output one after the other). The reason why I would not want to use the queue is that I'd want the UI of my program (such as metronome ticks and counts) to somehow synch with the sound that is being heard. I've tried removing all UI elements, thinking that the UI controls might have caused the delay, but still the ritardando effect persists. The structure of my code is like this: parse_midi_file(); merge_all_tracks_to_one_single_track(); normalize_the_delta_times() for all events; do usleep(delta_time_for_each_event); play_the_event_using_alsa_direct_output(); done The ritardando effect is a bit lesser using 2.6 kernels. If I use queues, the problem disappears completely in 2.4 and 2.6 kernels. I don't hear the effect with simple MIDI files, such as with piano pieces. By the way, I intend to use my app with a 2.4 kernel. Does anybody have a solution to the delay problem? Please point out to me if I'm doing anything wrong since I've just been working with alsa-seq for a few months. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp

2 4