Re: [Alsa-devel] Converted "Writing an ALSA Driver" to DocBook.
Patrick Shirkey wrote: nice. if you finish the set up, please let me know the url. i'll add it as the reference to the new version. Kevin sent me the html version and I have added it and the sgml file to the site. http://www.alsa-project.org/documentation.php3 The link to the html is http://www.alsa-project.org/alsa-doc/doc-components/writing-an-alsa-driver/ IIUC the only thing we are missing for documentation is a comprehensive rundown of the midi api. That means in the past year we have nailed the documentation crisis for alsa-project. No longer can people complain about docs not exisiting only that they are not relevant :) Everyone involved deserves a pat on the back. Best regards. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman --- 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] ymfpci, big-endian, and spdif out
On Thu, 2 Jan 2003, Troy Benjegerdes wrote: > I have a mac G4 (running debian testing), a ymfpci card (MaxiSound > Fortissimo) with optical TOSlink out, and a yamaha HTR-5540 receiver with > digital optical TOSlink input. > > I'm trying to get xine or some other DVD player to output AC/3 sound to > the receiver for watching dvd's, and I have a couple of problems. > > 1) xmms (and xine 2-channel sound) works with OSS emulation, but is static > with native ALSA drivers. This seems like some endian problem > > 2) spdif out does not seem to work. Here are some of the messages from > xine: > > audio_alsa_out : supported modes are 8bit mono stereo (4-channel not enabled in > xine config) (5-channel not enabled in xine config) (5.1-channel not enabled in > xine config) a/52 and DTS pass-through > > > audio_out: stream audio format is 48000 kHz sampling rate, 16 bits. mode is 1. > audio_alsa_out: Audio Device name = > iec958:AES0=0x6,AES1=0x82,AES2=0x0,AES3=0x2 > audio_alsa_out: Number of channels = 2 > audio_alsa_out: pcm hw_params failed: No such device or ALSA lib > pcm_hw.c:292:(snd_pcm_hw_hw_params) SNDRV_PCM_IOCTL_HW_PARAMS failed: No > such device or addressALSA lib pcm_hw.c:292:(snd_pcm_hw_hw_params) > SNDRV_PCM_IOCTL_HW_PARAMS failed: No such device or address > > > So where do I get started to fix this? > > Also, where can I get some short raw AC3 encoded sounds to test with > something like aplay? We have command-line ac3dec in our alsa-tools package. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- 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] cmipci problem
Hi, cmipci.c doesn't compile using CVS from today. Hmm, "global_list" is a little bit strange there I think bye, martin In file included from cmipci.c:1: ../alsa-kernel/pci/cmipci.c: In function snd_cmipci_create': ../alsa-kernel/pci/cmipci.c:2957: warning: assignment from incompatible pointer type ../alsa-kernel/pci/cmipci.c:2957: warning: comparison of distinct pointer types lacks a cast ../alsa-kernel/pci/cmipci.c:2957: structure has no member named global_list' make[2]: *** [cmipci.o] Error 1 make[2]: Leaving directory /usr/local/src/alsa-cvs/alsa-driver/pci' make[1]: *** [compile] Error 1 make[1]: Leaving directory /usr/local/src/alsa-cvs/alsa-driver' make: *** [build] Error 2 --- 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] Digital sound card conventions
I'm doing a maintenance update on the rme96 driver, and I wonder if there are any conventions to follow in the driver concerning digital sound cards. The specific questions are how to handle sample rates and sound formats on the input. The sound card supports several sample rates and formats. What should happen if the user tries to open the input with 48000 kHz ADAT, but the format is actually 44100 kHz and SPDIF? I can allow it if I want to, the user will get data, but at 48000 kHz of course. What should happen when there is no input signal at all? The hardware supports opening the input, but should I do so in the driver? The signal can of course change in runtime as well... I'm thinking of allowing it all, but I don't know if that is the right way to go. /Anders Torger --- 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] Re: Digital sound card conventions
On Fri, 3 Jan 2003, Anders Torger wrote: > I'm doing a maintenance update on the rme96 driver, and I wonder if > there are any conventions to follow in the driver concerning digital > sound cards. > > The specific questions are how to handle sample rates and sound formats > on the input. > > The sound card supports several sample rates and formats. What should > happen if the user tries to open the input with 48000 kHz ADAT, but the > format is actually 44100 kHz and SPDIF? I can allow it if I want to, > the user will get data, but at 48000 kHz of course. > > What should happen when there is no input signal at all? The hardware > supports opening the input, but should I do so in the driver? > > The signal can of course change in runtime as well... > > I'm thinking of allowing it all, but I don't know if that is the right > way to go. This part of PCM API has not been discussed. I think that we should follow the most easy way: It is - allow only sample rate given by application, if the master clock is using another sample rate - in trigger() callback - driver will fail. Also it will fail, when sample rate is changed during operation. We probably need to add a new PCM state - SNDRV_PCM_STATE_STREAM_CHANGED (equal to DRAINING, but informative for applications). The notification of master clock / sample rate (or other parameter) changes should be implemented using the control API. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- 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: Digital sound card conventions
On Friday 03 January 2003 21.33, Jaroslav Kysela wrote: > On Fri, 3 Jan 2003, Anders Torger wrote: > > I'm doing a maintenance update on the rme96 driver, and I wonder if > > there are any conventions to follow in the driver concerning > > digital sound cards. > > > > The specific questions are how to handle sample rates and sound > > formats on the input. > > > > The sound card supports several sample rates and formats. What > > should happen if the user tries to open the input with 48000 kHz > > ADAT, but the format is actually 44100 kHz and SPDIF? I can allow > > it if I want to, the user will get data, but at 48000 kHz of > > course. > > > > What should happen when there is no input signal at all? The > > hardware supports opening the input, but should I do so in the > > driver? > > > > The signal can of course change in runtime as well... > > > > I'm thinking of allowing it all, but I don't know if that is the > > right way to go. > > This part of PCM API has not been discussed. I think that we should > follow the most easy way: It is - allow only sample rate given by > application, if the master clock is using another sample rate - in > trigger() callback - driver will fail. Also it will fail, when sample > rate is changed during operation. We probably need to add a new PCM > state - > SNDRV_PCM_STATE_STREAM_CHANGED (equal to DRAINING, but informative > for applications). The notification of master clock / sample rate (or > other parameter) changes should be implemented using the control API. So what you are saying is, for now, do what is correct at the moment. Is this ok: If no signal on the input - allow to open with any setting the hardware supports. The current rme96 driver will return -EIO, but that sucks if you're just opening the card to check some parameters, so I plan to change that. If there is a signal on the input, limit the reported sound card capabilities to only those currently available on the input, so when the sound card is opened for capture, it seems only capable of 48kHz if that is the current sample rate. /Anders Torger --- 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: Digital sound card conventions
> >This part of PCM API has not been discussed. I think that we should follow >the most easy way: It is - allow only sample rate given by application, if >the master clock is using another sample rate - in trigger() callback - >driver will fail. this seems wrong to me. what should fail is an attempt to set the sample rate unless the hardware is its own clock Master. if no attempt is made to set it, then the application gets whatever the hardware is running at, whether that is externally controlled or some h/w specific default. > Also it will fail, when sample rate is changed during >operation. the hammerfall driver used to contain stubs for doing this. every read/write operation would check that the (possibly externally controlled) SR was the same as "last time". i never did any more on this. > We probably need to add a new PCM state - >SNDRV_PCM_STATE_STREAM_CHANGED (equal to DRAINING, but informative for >applications). The notification of master clock / sample rate (or other >parameter) changes should be implemented using the control API. and already is for some cards (and some parameters). --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
Re: [Alsa-devel] Re: Digital sound card conventions
On Friday 03 January 2003 22.47, Paul Davis wrote: > >This part of PCM API has not been discussed. I think that we should > > follow the most easy way: It is - allow only sample rate given by > > application, if the master clock is using another sample rate - in > > trigger() callback - driver will fail. > > this seems wrong to me. what should fail is an attempt to set the > sample rate unless the hardware is its own clock Master. if no > attempt is made to set it, then the application gets whatever the > hardware is running at, whether that is externally controlled or some > h/w specific default. An attempt to set it to the sample rate that happens be the correct one should be ok, at least I think so. So, your suggestion is, that for capture, always state the full hardware capability (in hwparams), but fail if incorrect the settings are made? I think that is ok too, but currently I'm narrowing down the hwparams to fit what is available at the input when the sound card is opened (of course, that could have changed until the sound card is started, but it is quite unlikely). I think both approaches are ok, but narrowing down the alternatives I think is more nice to the applications. My guess is that the common use of a digital sound card is that the input signal is not changed too often, and then it is nice if the software gets the correct capabilities, so those applications that think that all sound cards are analog will work in the expected way anyway. > >Also it will fail, when sample rate is changed during > >operation. > > the hammerfall driver used to contain stubs for doing this. every > read/write operation would check that the (possibly externally > controlled) SR was the same as "last time". i never did any more on > this. Uhmm... I don't think I will include changed sample rate / format callback stuff for now, because I don't know how to implement it. However, if there is a good example which I could imitate, let me know. /Anders Torger --- 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] How to support multiple open in low-level driver
I have noticed that some (most) low level drivers support multiple open, that is a sound card which is already opened, can be opened again. I noticed that also my rme96 driver supported this sort of, although it probably does not feel very good about it. If the sound card is in ADAT mode, it is not so good if it is reopened in SPDIF mode from another application for example. I'd like to just return -EBUSY if it is already open, is that ok? /Anders Torger --- 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] cs46xx - Terratec DMX XFire 1024
[EMAIL PROTECTED] wrote: The following has been submitted as a note for the documentation of cs46xx. Richard Stevens Friday, 03 January 2003 Terratec DMX XFire 1024: The DMX XFire 1024 doesn't get initialized correctly the first time the alsa modules are loaded. Sound is heavily distorted. Usually reloading the modules solves this problem. One can do that autmatically by loading, unloading and reloading the modules in the bootscripts. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman --- 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
