Re: [Alsa-devel] alsa-conf will not compile.
At Sat, 29 Jun 2002 21:37:31 +0200, Joern Nettingsmeier wrote: Takashi Iwai wrote: At Tue, 25 Jun 2002 01:27:53 +0100, James Courtier-Dutton wrote: Has anyone managed to get alsa-conf to compile ? I use the current CVS, but it will not compile. Is alsa-conf of any use any more ? no, it's not maintained atm. it was designed for the old system. since then, some things have been changed. iirc the following problems have to be solved: - rewrite the parser for outputs of new modprobe/modinfo - rewrite the code to use snd-xxx instead of snd-card-xxx - the module syntax description was moved from the built-in module description to /lib/modules/XXX/modules.generic_string. the parser must look at the latter file. since SuSE 8.0 autoconfigures ALSA in a breeze, perhaps they might be willing to share some of their yast2 magic ? ;) hint / if ycp language becomes standard over the world ;) (yast2 configurator uses its own script language.) i myself don't touch much with yast2 development but just helped debugging... btw, for configuration of a single card, the modified alsaconf script might be helpful: ftp://ftp.suse.com/pub/people/tiwai/misc/alsaconf this is based on the old alsaconf shell script but enhanced with pci/pnp detection. it can detect even some of old isa chips without pnp (not always fully functional, though). Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] rme96 and adat, problems opening for capture when clock-master
Hello, I am using a rme 96/8 card. I encounter a problem whenever I try to open the adat device, which is the second device on the card, for capture. I get an input/output error. The problem occurs when I switch from spdif to adat (from hw:0,0 to hw:0,1 in my case) _and_ the clock mode is master. If I set the card to slave mode and change the settings on my adda converter, there is no problem. Playback only will always work. So f.i. if I start pd, with hw:0,1 as audio device, I have to start once , with an error message that it can't open the card for capture. Then I quit, and start pd again. The second time it works for capture as well as for playback. Is this a bug in the driver? regards Gerard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [linux-audio-user] USB sound
Takashi Iwai wrote: Patrick Shirkey wrote: Speaker to Vegetables wrote: Stuff that goes in the kernel is harder to install and usually harder to use. In this case, a kernel driver would be easier to use because it would be integrated in the ALSA framework. The daemon currently must be downloaded and compiled seperately. OTOH, the daemon could be added to the alsa-tools package easily. The golden reason for putting anything in a kernel-level driver is when that's the only way to get it to perform well enough. Good point but then if then we shouldn't have included ALSA if that is true. The ALSA code base is large and having the usb midi module as a userland app seems to me to go against the precendant set by the rest of the modules. Yes. Most users expect all drivers to be kernel modules. Not being able to do lsmod/modprobe/rmmod makes diagnosing problems harder. another reason pushing me against the implementation of kernel driver is that usb midi specification is not followed by all vendors. apparently, the spec is half-finished. there is little devices which can be handeld properly by the existing usb-midi kernel driver without any workaround. All devices understand the USB MIDI protocol AFAIK. The problem with most devices is that the USB descriptors are broken or missing, so some information must be supplied for them. unfortunately i myself don't have a midi usb device yet, so i cannot say 100% surely on how much latency this solution works. but i think that the scheduled thread should work with enough small latency comparable with a kernel module. USB host controllers (at least UHCI) don't issue an interrupt before the end of the 1ms frame. The additional latency of either driver or daemon should be negligible. On the other hand, there may be issues with task scheduling -- the daemon uses SCHED_FIFO with priority 99, but so does Timidity. On the gripping hand, I've now written a kernel driver (see my other post to alsa-devel). With both available, I predict that nobody will want to risk the (theoretically) higher latency of the daemon. Requiescat in pacem. :-) Clemens --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] poll_descriptors_count
yes. see the internals of JACK's jack/drivers/alsa/alsa_driver.c Honestly, I'm afraid to look at that file too carefully since it is GPL and PortAudio is BSD. This puts me in kind of a weird situation. nobody is going to come after you for an extremely similar implementation. the GPL doesn't prohibit intellectual inspiration - you just can't copy paste. Also, is snd_pcm_poll_descriptors_revents() understood to return the events that have triggered on just *one* poll descriptor or on *all*? In other words, are you ANDing bitmasks or ORing them? Right now the semantics are impossible to deduce because the function just returns the revents verbatim since there is only one poll descriptor. The semantics are those of POSIX poll(2): it returns the status for Drat! I missed that fact that you were talking about snd_pcm_poll_descriptors_revents(), not poll(2) revents. I don't use this function at all, considering it something of it a band-aid. Are you saying that the revents paramter is treated as an array? I was under the impression that it is treated as a pointer to a single short. This code fragment from test/pcm.c seems to confirm this interpretation: You're right. But then again, I don't use wait_for_poll or the variant on its theme that exists in alsa-lib, because its not written correctly for multithreaded and some other code (mostly related to handling errors while blocked on poll(2)). This gives me the impression that snd_pcm_poll_descriptors_revents() is a function that somehow summarizes all of the pfds into a single revents that speaks to the status of the entire PCM handle. Yes, that's definitely the intent of the function. --p --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Higher level functions.
Is there, or plans for higer level function in alsa lib for motorized midi controlers? Like Steinberg Houston or Mackie HUI? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Analog Devices AD1887 support
I'm trying to get sound working on an IBM NetVista X41 model 2283, an Intel P4 all-in-one computer with limited expansion capability (no full-size PCI slots). I built Alsa from CVS on Red Hat 7.3, kernel 2.4.18-5. This unit has the Analog Devices AD1887 chip on the motherboard. I specified snd-intel8x0 in /etc/modules.conf. The module loads, I unmuted and set levels in the mixer, audio applications appear to work, but no sound comes out. I suspect this is very close to working, but I don't know where to proceed from here. The soundcard matrix mentions the AD1885 and AD1886 but not the AD1887. Has anyone got this chipset working yet? If someone can guide me in the right direction I can probably get this working myself, assuming the changes are small relative to the existing AD188x chips. This message shows up in /var/log/messages: Jun 22 13:52:14 xp2 kernel: PCI: Setting latency timer of device 00:1f.5 to 64 Jun 22 13:52:16 xp2 kernel: intel8x0: clocking to 41138 And this is from /proc/pci: Bus 0, device 31, function 5: Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio (rev 18). IRQ 5. I/O at 0x1c00 [0x1cff]. I/O at 0x1880 [0x18bf]. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] poll_descriptors_count
On Mon, 1 Jul 2002, Joshua Haberman wrote:
* Paul Davis ([EMAIL PROTECTED]) wrote:
Also, how should programs interpret multiple poll descriptors: if the
poll succeeds on some descriptors but not others, does this mean the
stream is only partially ready?
yes. see the internals of JACK's jack/drivers/alsa/alsa_driver.c
Honestly, I'm afraid to look at that file too carefully since it is GPL
and PortAudio is BSD. This puts me in kind of a weird situation.
Also, is snd_pcm_poll_descriptors_revents() understood to return the
events that have triggered on just *one* poll descriptor or on *all*? In
other words, are you ANDing bitmasks or ORing them? Right now the
semantics are impossible to deduce because the function just returns the
revents verbatim since there is only one poll descriptor.
The semantics are those of POSIX poll(2): it returns the status for
each file descriptor. ALSA's low level and mid level drivers don't
modify this in anyway. If there 3 fd's for playback and 2 for capture,
then the return data would indicate status for each of the 5 fd's
(assuming you asked for it for all 5).
The prototype for this function is:
int snd_pcm_poll_descriptors_revents ( snd_pcm_t *pcm,
struct pollfd *pfds,
unsigned int nfds,
unsigned short * revents
)
Are you saying that the revents paramter is treated as an array? I was
under the impression that it is treated as a pointer to a single short.
This code fragment from test/pcm.c seems to confirm this interpretation:
static int wait_for_poll(snd_pcm_t *handle, struct pollfd *ufds, unsigned
int count)
{
unsigned short revents;
while (1) {
poll(ufds, count, -1);
snd_pcm_poll_descriptors_revents(handle, ufds, count, revents);
if (revents POLLERR)
return -EIO;
if (revents POLLOUT)
return 0;
}
}
This gives me the impression that snd_pcm_poll_descriptors_revents() is a
function that somehow summarizes all of the pfds into a single revents
that speaks to the status of the entire PCM handle.
Yes, it translates multiple revents into one for application. Please, use
this function for the library flexibility.
Jaroslav
-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project http://www.alsa-project.org
SuSE Linuxhttp://www.suse.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rate Conversion
Paul Davis wrote: You don't need to do this. Use the 'plughw' device which should do all conversions from you. I am a little confused about your advice. I am not sure how to access the 'plughw' device from my application. snd_pcm_open (handle, plughw:N,M, ...) where N and M are the card number and subdevice number. Preferably, this is a string supplied by the user, not hard coded into the application. I am not sure of how I should be setting up my PCM devices. How do I tell them to convert, say, 8kHz audio data to 44.1kHz audio data so my hardware can play it at the correct speed? just as in the few token API examples. using snd_pcm_hw_params_*(). there is no difference setting the parameters no matter what type of PCM device you are using. If use the virtual plughw:0,0 device and set the rate to 8kHz, at what rate is my actual hardware device set to? Where are these settings made and how are they decided? Do I need to, or is it possible to, tell my soundcard to operate at 44.1kHz? Kris Modrak --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
