RE: [Alsa-devel] depmod -ae errors
In follow up to this. The problem seems to be the failure to properly expand: snd_runtime_check macro in include/driver.h Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James Courtier-Dutton Sent: 18 November 2001 21:00 To: [EMAIL PROTECTED] Subject: [Alsa-devel] depmod -ae errors Unresolved symbols in /lib/modules/2.4.9/misc/snd-mixer-oss.o read_unlock I enclose a tar.gz file with the command I used to compile, together with output during make. Can anyone help? -- Nothing in this world is exactly what it appears to be. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] MMAP mode
Hello I use ac3dec which comes with alsa as a very nice example on how to program the alsa-lib for PCM out. Is there a similar program showing how to use MMAP output ? I would like to update the xine media player to use MMAP. Cheers James -- Nothing in this world is exactly what it appears to be. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] kernel 2.5.0
Will that mean that alsa-driver will be in the kernel. Where will alsa-lib, alsa-utils and alsa-tools go ? Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] more on that return from poll(2) issue
I don't know all about mmap, but why does one need to poll.
I would have thought that a callback with info on how many samples it wants
would be a better way.
Cheers
James
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis
Sent: 28 November 2001 13:47
To: Jaroslav Kysela
Cc: [EMAIL PROTECTED]
Subject: Re: [Alsa-devel] more on that return from poll(2) issue
non-continous transfers. The right loop, based on the period_size
transfers, should be like this:
poll();
if ((pfd-revents POLLIN) {
while (1) {
if (snd_pcm_avail_update(pcm) period_size)
break;
count = period_size;
// transfer whole period (can be composed from more
// non-continuous parts)
right, i understand that on some hardware, this is true. but there is
no reason i know of for the trident h/w (perhaps for any hardware) to
have a whole period composed of 2 non-continuous parts of size 1 and
(period_size-1) frames. i can't believe that its an honest reflection
of the state of the hardware.
the one complication that i can see that might cause this is the
extent to which capture+playback hw pointers are in sync. what might
be happening is that there really is a continuous period_size's worth
of frames available on one stream, but in the other stream, the
pointer doesn't quite reflect this, so we end up with the silly
situation of having (period_size-1) + 1 frames. you'll note that in the
code below, i poll only one descriptor.
do you think this is possible/likely? if it is, do you think that its
the job of the low level driver(s) to handle this? otherwise, its hard
for me to see how an application (or library) can handle this
efficiently in any full-duplex situations.
i say this because even if we poll on both stream descriptors, if one
of them is out-of-step by 1 (or lets just say some very small number
of frames), we have to go back into poll immediately, which will
return immediately, and we end up busy waiting, which is not good at all.
i don't see any other way to handle that situation. do you?
i'm going to add some debugging to check on the pointers-not-in-sync
theory, and i'll let you know what i find. since very few programs do
full duplex operation, this may be a rather hidden problem.
while (avail 0) {
frames = count;
snd_pcm_mmap_begin(pcm, areas,
offset, frames
);
snd_pcm_mmap_commit(pcm, offset, frames);
count -= frames;
}
}
}
is there any difference between that and the actual loop (a few
non-essentials removed to make it clearer):
if (poll (driver-pfd, 1, 1000) 0) {
error ...
}
if (driver-pfd.revents POLLERR) {
error
}
if (driver-pfd.revents == 0) {
... timeout
}
if ((capture_avail = snd_pcm_avail_update
(driver-capture_handle)) 0) {
... detect xruns ...
}
if ((playback_avail = snd_pcm_avail_update
(driver-playback_handle)) 0) {
... detect xruns ...
}
... handle xruns ...
avail = capture_avail playback_avail ?
capture_avail : playback_avail;
while (avail) {
/* driver-frames_per_cycle === period_size */
capture_avail = (avail driver-frames_per_cycle) ?
driver-frames_per_cycle : avail;
playback_avail = (avail driver-frames_per_cycle) ?
driver-frames_per_cycle : avail;
/* THIS CALLS snd_pcm_mmap_begin() FOR BOTH STREAMS */
if (alsa_driver_get_channel_addresses
(driver,
(snd_pcm_uframes_t *) capture_avail,
(snd_pcm_uframes_t *) playback_avail,
capture_offset, playback_offset) 0) {
return -1;
}
contiguous = capture_avail playback_avail ?
capture_avail : playback_avail;
do interesting stuff with `contiguous' frames ...
snd_pcm_mmap_commit (driver-capture_handle,
capture_offset, contiguous);
snd_pcm_mmap_commit (driver-playback_handle,
playback_offset, contiguous);
avail -= contiguous;
}
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
___
Alsa-devel
[Alsa-devel] YMF744 - Yamaha DS-XG PCI (YMF744) (ymfpci driver) Bugs in snd_pcm_hw_params_set_period_size_near.
Hello With the following card: - YMF744 - Yamaha DS-XG PCI (YMF744) (ymfpci driver) Why does: - tmp = snd_pcm_hw_params_set_period_size_near(this-audio_fd, params, period_size, 0); give tmp=257 no matter what value you give period_size ? Is the period_size fixed on this card? Cheers James -- Nothing in this world is exactly what it appears to be. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Philips Acoustic Edge
If hardware manufactures wanted their products to have good support on Linux, all they have to do is publish the hardware programming details, and the linux community will do the actual driver development. I still don't understand what manufactures are protecting by not releasing the programming details needed for 3rd parties to develope their own drivers. All chip only manufactures publish the details. I don't have any Philips hardware, but there is a principal here. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis Sent: 12 October 2001 12:59 To: J rn Nettingsmeier Cc: Michael Staggs; [EMAIL PROTECTED] Subject: Re: [Alsa-devel] Philips Acoustic Edge it's been the same with MOTU, some vendors are just ignorant of a large potential customer base. lets not kid ourselves. there is a *tiny* potential customer base for the next several years at least, and the existing customer base is even smaller. the customer base for audio chipsets in things like laptops and off-the-shelf desktops is quite a bit larger, but anything that's actually a serious audio interface has a linux customer base that can probably be counted in the low hundreds, if that. or so it seems to me. even if i'm wrong, i suspect that even the most optimistic vision of the customer base doesn't justify the investment these kind of inertia-bound companies think they have to make to get into Linux. --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] D-class amp...
What is wrong with using a PC ? Use all 8 bits of the parallel port in DMA mode. The make an external circuit which will buffer and then serial clock the 8 bits out. If this is not quick enough, use more parallel ports. It is probably a good idea to use a real time OS, and not linux. Linux currently, is not best suited to low latency applications efficiently. Something like PLAN 9 might suit better. It is probably overkill for something as simple as a D-Class amplifier, but it will be a good development system. If you write everything in C, it should be easily ported to an embedded system later. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tomek Cedro Sent: 15 October 2001 22:16 To: [EMAIL PROTECTED] Subject: [Alsa-devel] D-class amp... Hi! I've resigned to use linux box as a D-class amplifier. I've diecided to make standalone device. Why? The biggest problem is that serial/parallel port's max. output frequency is 370kHz... It could be usefull, but I don't want to make my life harder - as I often like to do ;) I'm planning to use MAXIM's signal generator or motorola fast microcontroller, maybe dallas 80Cxxx or atmel's AT90Sxxx. Day by day I'm thinking about great Intel's microprocessors efficiency... and I'm really considering switchng to MOTOROLA for good :) I don't want to piss off anyoune, but I think that those guys who tols me so many bad things abut --GNU-- assembler, should read assembly-howto... I was not talking abut -NASM-. Never mind... peace! ATARI RULZ! :] Once again thanks for all help and sugestions! I'll call You when device ready... TANKS! CeDeROM/KSZAK ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] YMF744 - Yamaha DS-XG PCI (YMF744) (ymfpci driver) Bugs in snd_pcm_hw_params_set_period_size_near.
Ok, where should I start looking for the bug? I have been looking, but I have not found yet, where the valid period sizes are set. I would imagine that this would be in the alsa-driver, but snd_pcm_hw_params_set_period_size_near does not seem to call the alsa-driver. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jaroslav Kysela Sent: 29 November 2001 21:25 To: James Courtier-Dutton Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] YMF744 - Yamaha DS-XG PCI (YMF744) (ymfpci driver) Bugs in snd_pcm_hw_params_set_period_size_near. On Thu, 29 Nov 2001, James Courtier-Dutton wrote: Hello With the following card: - YMF744 - Yamaha DS-XG PCI (YMF744) (ymfpci driver) Why does: - tmp = snd_pcm_hw_params_set_period_size_near(this-audio_fd, params, period_size, 0); give tmp=257 no matter what value you give period_size ? Is the period_size fixed on this card? You got it. It is fixed to 256 frames at 48kHz. The value 257 is probably caused with some rounding (and should be fixed, of course). Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] SuSE Linuxhttp://www.suse.com ALSA Project http://www.alsa-project.org ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] audigy specs
This would probably be best done with the people at mailto:[EMAIL PROTECTED] (http://opensource.creative.com) They already have sound coming out of the audigy, so it would be better to only ask for stuff the emu10k1-devel people don't already know about. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chuck Busby Sent: 03 December 2001 20:57 To: alsa developement Subject: [Alsa-devel] audigy specs Hi - I got an answer back from my buddy at EMU. He says he hasn't been working directly with the SBLive! guys for a while, but still has connections. (He is one of the founders of EMU) He asked me What exactly are you looking for? I don't think this is an open system. So if you can send me a specs wish list, I _may_ be able to get specs thru him. He made no mention of any kind of non-disclosure agreement. Chuck Busby [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] This may be a one shot deal so I e-mailed so I wouldn't leave anything out in my request. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] linux sound card w/ digital output
I think only few cards support the detection of non-audio data format on hardware. And as mentioned before, on some chips, the stream is resampled on other rates.. Takashi Can anyone tell me which cards do NOT do resampling on SPDIF IN so Recording AC3 works. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] linux sound card w/ digital output
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Takashi Iwai Sent: 04 December 2001 09:31 To: Joshua Jacobs Cc: Dan Hollis; [EMAIL PROTECTED] Subject: Re: [Alsa-devel] linux sound card w/ digital output Hi Josh, At Mon, 03 Dec 2001 14:59:38 -0500, Joshua Jacobs wrote: I had posted earlier about finding a sound card which supports toslink output under linux. It appears that Dan's page http://www.alsa-project.org/~goemon/ has been updated to include an entry on the Fortissimo II and it shows that its toslink in and out are both supported. Thanks for the update. I'm going ahead and buying a fortissimo II. Wait, wait.. ALSA cs46xx driver still does _NOT_ support digital i/o! And it seems difficult to support it in near future, too, since Cirrus Logic doesn't want to release their DSP info. AFAIK, TOSLINK output should work on the following drivers: - RME9652 - RME96 - ICE1712 (Envy24) - Emu10k1 (SB Live!) - Trident 4D DX/NX - YMFPCI - FM801 - CM8738 The lower is often cheaper. And if you want digial input, please check the card carefully. Some cards have only internal connectors although digital input is stated on the product box.. ciao, Takashi Another thing to watch for is there are two types of SPDIF in. 1) SPDIF PCM Audio in. Recording normal stereo at different rates. 2) SPDIF non-audio in. (AC3, DTS etc.) The SB Live does (1) but NOT (2) I don't know the SPDIF capabilities of the other cards. I need a sound card capable of (2), but don't know which ones work. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] linux sound card w/ digital output
Did you notice that I was talking about SPDIF Digital IN not OUT. (IN = RECORD, OUT=PLAY). Most cards can do Digital OUT for AC3 etc, but fewer can do Digital IN for AC3 etc. Cheers James -Original Message- From: Takashi Iwai [mailto:[EMAIL PROTECTED]] Sent: 04 December 2001 10:52 To: James Courtier-Dutton Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] linux sound card w/ digital output At Tue, 4 Dec 2001 10:24:51 -, James Courtier-Dutton wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Takashi Iwai Sent: 04 December 2001 09:31 To: Joshua Jacobs Cc: Dan Hollis; [EMAIL PROTECTED] Subject: Re: [Alsa-devel] linux sound card w/ digital output Hi Josh, At Mon, 03 Dec 2001 14:59:38 -0500, Joshua Jacobs wrote: I had posted earlier about finding a sound card which supports toslink output under linux. It appears that Dan's page http://www.alsa-project.org/~goemon/ has been updated to include an entry on the Fortissimo II and it shows that its toslink in and out are both supported. Thanks for the update. I'm going ahead and buying a fortissimo II. Wait, wait.. ALSA cs46xx driver still does _NOT_ support digital i/o! And it seems difficult to support it in near future, too, since Cirrus Logic doesn't want to release their DSP info. AFAIK, TOSLINK output should work on the following drivers: - RME9652 - RME96 - ICE1712 (Envy24) - Emu10k1 (SB Live!) - Trident 4D DX/NX - YMFPCI - FM801 - CM8738 The lower is often cheaper. And if you want digial input, please check the card carefully. Some cards have only internal connectors although digital input is stated on the product box.. ciao, Takashi Another thing to watch for is there are two types of SPDIF in. 1) SPDIF PCM Audio in. Recording normal stereo at different rates. 2) SPDIF non-audio in. (AC3, DTS etc.) The SB Live does (1) but NOT (2) Hmm, i'm not sure how is the current status of emu10k1, but ac3 output was once enabled.. I don't know the SPDIF capabilities of the other cards. I need a sound card capable of (2), but don't know which ones work. The first three drivers support the non-audio data. The ice1712 based cards have many variance, and the digital i/o is dependent on chipset, though. But at least it's ok on M-Audio and TerraTec cards. (How about Hoontech DSP24??) The others, trident, ymfpci and cmipci drivers support non-audio digital, too. I don't know about fm801: there is a switch IEC958 Raw Data Playback Switch. Is it for enabling non-audio data transfer or not involved at all? Takashi ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] audigy specs
One thing I would like to know about the emu10k1 (SB Live). I noticed a register in the emu10k1 which has #define SPBYPASS0x5e/* SPDIF BYPASS mode register */ #define SPBYPASS_ENABLE 0x0001 /* Enable SPDIF bypass mode */ See attached 8010.h file for context. If this SPBYPASS_ENABLE is enabled, how do we pass data to and from the SPDIF sockets. It seems to stop any data passing to the SPDIF sockets from the DSP. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chuck Busby Sent: 03 December 2001 20:57 To: alsa developement Subject: [Alsa-devel] audigy specs Hi - I got an answer back from my buddy at EMU. He says he hasn't been working directly with the SBLive! guys for a while, but still has connections. (He is one of the founders of EMU) He asked me What exactly are you looking for? I don't think this is an open system. So if you can send me a specs wish list, I _may_ be able to get specs thru him. He made no mention of any kind of non-disclosure agreement. Chuck Busby [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] This may be a one shot deal so I e-mailed so I wouldn't leave anything out in my request. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel 8010.h Description: Binary data
[Alsa-devel] Using the sound card as the clock source to a DVD player.
Hello I would like to use the sound card as a clock source for a DVD player. I have a SB Live with alsa drivers 0.9.x. Which API call can I make to the sound card which is equivalent to the gettimeofday call? Also, what will be the units of time received from the call? Cheers James -- Nothing in this world is exactly what it appears to be. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] linux sound card w/ digital output
-Original Message- From: Jaroslav Kysela [mailto:[EMAIL PROTECTED]] Sent: 04 December 2001 13:07 To: James Courtier-Dutton Cc: Ricardo Colon; [EMAIL PROTECTED] Subject: RE: [Alsa-devel] linux sound card w/ digital output On Mon, 3 Dec 2001, James Courtier-Dutton wrote: Sort off. SPDIF-In PCM mode only. You cannot record AC3 or DTS SPDIF digital data. The SB Live sends all the samples through an interpolator, which is fine for PCM, but plays havoc with AC3 and DTS. The interpolator is not used for incoming samples. There is only SRC (sample rate converter), but it shouldn't change samples at 48kHz. Jaroslav Ah! If that is true I will do some recordings and see what happens. It failed last time with the recorded data being modified. If one is recording from the SPDIF, and one wants to record AC3 data, I.E. Non-audio bit set. What settings should one make in the mixer so that no modifications happen to the input. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] set_period_size gives error: Invalid argument
When I see -22 returned, it normally means wrongly installed drivers. Most users who report -22 errors, find the solution is a re-install of alsa fixes it. This is what I have found from users of xine (http://xine.sf.net) which has alsa support. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jack Moffitt Sent: 19 December 2001 07:44 To: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] set_period_size gives error: Invalid argument You may try to use snd_pcm_hw_set_period_size_near(). There might be some hardware constraints which do not allow to use any integer period size. If you feel it's a bug, let me know. Same error with that as well. I think this is a bug. I tried tracing through the code in src/pcm/pcm_param.c and various other places where this codepath leads, but I was quickly lost. I am not sure how this is all supposed to work and there's not a lot of helpful comments :) _snd_pcm_hw_param_set() is returning -22 which I assume is -EINVAL. This seems to be coming from the alsa-kernel code and that's about where I got lost. Is there not a function to get the optimal periods/periodsize? Maybe setting up the hw_params explicitly (except for rate and channels) is a bad way to go about things? jack. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Alsa and the future of sound on Linux
I personally think that PCM audio is not easy to deal with, when one needs to do effects on it etc. PCM is only a representation of the sound, why do we HAVE to use it? It seems to me that a much better format for storing and manipulating sound it is the in frequency density domain. After all, that is how our ears hear it, nerve endings send signals to our brains based on the amplitude of the sound at a particular frequency. There are lots of nerve endings in the ear listening to different frequencies. Then one will have a small packet of bytes which describe the sound based on the amplitude and phase at particular frequencies at a particular time. This can be extended to describe the rate of change of each amplitude and phase at that particular time thus providing a prediction of what should happen to the amplitude and phase until the next packet arrives with new instructions. All one would then have to do is label the packet with a time stamp, and the computer could easily mix two or more streams together in perfect sync and use simple message passing between audio apps. Computers are much better at handling packets of data, instead of streams of data. Most sound apps have to turn the PCM into the frequency domain before applying a sound effect anyway, why not just stay in the frequency domain. I believe that alsa just provides the final computer to Loud Speaker interface. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis Sent: 11 January 2002 18:10 To: Mark Constable Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] Alsa and the future of sound on Linux Paul, could you spare some more keystrokes on what you think are the best steps to take to solve this problem ? actually, i don't see a way forward. neither jaroslav nor abramo have indicated that they accept the desirability of imposing a synchronously executed API (SE-API; this being the heart of what ties CoreAudio, VST, MAS, TDM, JACK, LADSPA and others together as similar designs). abramo has questioned, in good faith and with the best of intentions, whether i am even correct that an SE-API is really what we need at all, and he has certainly vigorously questioned the adoption of a single format for linear PCM audio data (another thing that is shared by the systems named above). i think he's wrong, but he's certainly not alone in his opinions, and not stupid either. therefore, its going to continue to be possible to write applications with ALSA (and by extension, OSS, since ALSA will support the OSS API indefinitely) that will not integrate correctly into an SE-API executed API. ALSA itself is quite capable of being used to with an SE-API, it just doesn't enforce it. desktop-centric folks will probably be paying attention to CSL and artsd, which don't integrate correctly into an SE-API, and separately, the game developers will continue to use stuff like SDL which provides its own audio API, again not capable of integrating correctly with an SE-API. most linux folk simply don't understand (and don't want to understand) why synchronous execution is the key design feature. i think that this is in part because it implies totally different programming models from those they are used to, and in part because it somewhat implies multithreaded applications, which most people tend to be intimidated by. because linux isn't a corporate entity, there is no way for anyone to impose a particular API design on anyone. the best we can do is to provide compelling reasons for adopting a particular API. artds and CSL offers desktop-oriented developers and users something quite desirable right now. only by offering an API and documentation *and applications* that demonstrate more desirable properties will we be able to get beyond the open/read/write/close model that continues to hamper audio development on linux. my own hope is that once i can demonstrate JACK hosting ardour, rythmnlab as a polymetric drum machine, alsaplayer for wave file playback, and possibly MusE, all with sample-accurate sync and perfect audio data exchange between them, people will realize the benefits of shifting towards an SE-API, at which time, there can be a more productive discussion of the correct form and details of that API. i think that CoreAudio has made a couple of mistakes and suffers from an Apple programming style that while easier on the eyes than MS Hungarian, it still a bit inimical to standard Unix programmers. does that help? --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Alsa and the future of sound on Linux
I originally was trying to talk about sound formats like AC3 and DTS which store sound in small packets of FFT results, instead of the equivalent which would be small groups of PCM samples. So people could do processing on FFT sound sources without having to push them to PCM before they can be modified. For simplicity, I was ignoring the extra compression which DTS and AC3 do. That is what I meant by the frequency domain instead of the direct sample domain. Both would have a time domain component. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Harris Sent: 14 January 2002 10:24 To: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] Alsa and the future of sound on Linux On Sun, Jan 13, 2002 at 04:21:20 +0100, Thomas Tonino wrote: All are in the time domain, with maybe an exception or 2. And MP3 is not one of them. Even stuff that people think is frequency domain, is time domain too. MP3 is packets in linear time, each in the frequency domain. Thats usually what people mean when they say things are in the frequency domain. ie. overlapping packets of FFT results. - Steve ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Alsa and the future of sound on Linux
Paul, As you obviously know more about Jack than I do, can you explain how an API like Jack could provide information to the APP so that Audio and Video can be kept in sync. Cheers James -Original Message- From: Paul Davis [mailto:[EMAIL PROTECTED]] Sent: 14 January 2002 15:30 To: James Courtier-Dutton Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] Alsa and the future of sound on Linux I have looked at the Jack web page (http://jackit.sourceforge.net/) It would help more if jack.h had more documentation for all api function, and not just a few of them. well, we're not quite finished with the API yet. Once its really set in stone (for v1.0), something that i imagine will happen once i finish getting ardour to work with it (which is shaking out a lot of big issues that need addressing for supporting a large, complex application like ardour), full documentation will be added to the header file. its important, however, that the API stay simple for simple things. the sample clients in the current tarball are meant to illustrate just how simple things can be. I have a particular application in mind, and was wondering how Jack would handle it. 1) Audio and Video Sync Here there is no requirement for low latency or synchronous execution. The requirement is just that the app is told exactly how long it will be between the next samples written to the driver, and there is no such information in an SE-API system. all you get told is how much time we expect you to generate and/or process data for in this instance of your callback. SE-API's do not promise continuous execution, nor linear passage of time, nor monotonic direction of time. this is true of ASIO, VST, CoreAudio, PortAudio, TDM and every other SE-API that I know of. so, when your JACK client's process() callback is executed, it will be passed an audio frame count (we are debating whether this is the best or only unit of time to use). the process() callback is expected to do the right thing for the amount of time represented by those frames. if its an audio playback client, it will ensure that that many frames are present at all of its output ports. if its an audio capture client, it will read that many frames from each of its input ports and do something (probably lock-free and very fast) with them. if it a video client with audio playback, it will probably act like the audio playback client and additionally schedule another thread to handle video and/or update the video thread's idea of current time. and so on and so forth. if the client cares about absolute time against a reference time base, it must pay attention to information about where we are in time that can be otained through the API. a client that is not the timebase master must be ready to accept that time may move at different rates, may move backwards or stop altogether. --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] SB Live rev 6 cards and AC3 SPDIF passthru finally works! Patch attached.
Hello I enclose a patch to alsa09, which fixes the problems I have been having regarding no AC3 output from the SPDIF out. I don't know if anyone remembers, but I have been having problems with my SB Live card and AC3 out for a long time. I could get AC3 passthru working with the opensource.creative.com emu10k1 driver, but it never worked with the alsa09 driver. I had a free moment, so I tried hacking the alsa09 code a bit, to see what was happening. This patch finally fixes it for me at last. :-) Can someone please add this to the alsa 09 CVS ? Cheers James -- Nothing in this world is exactly what it appears to be. alsa-emu10k1-ac3-fix.diff Description: Binary data
RE: [Alsa-devel] Audigy support status
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Takashi Iwai Sent: 01 February 2002 19:20 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Alsa-devel] Audigy support status Hi, snip - digital non-audio i/o - not implemented no TRAM access yet You will not need TRAM access for the audigy. You can use the NULL resampler, interpolator instead. Some of the later SB Live cards also support the NULL interpolator. There was some explanation of how to do this on the emu10k1 list some time ago. ciao, Takashi ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] easy API examples?
I would try to use the 0.9.x API if you can. Although 0.9.x is beta, the api is mostly stable, and has better features. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Gerald Grabner Sent: 31 January 2002 22:19 To: [EMAIL PROTECTED] Subject: [Alsa-devel] easy API examples? Hi, is there any place where I could find easy examples of how to use the alsa 0.5 API? Something like just listening to a midi port and printing the incoming events on the standard output... Would be great to get started! Thx a lot in advance, Gerald ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Writing a low level sound card driver for alsa.
Hello I am thinking of writing a low level sound card driver for alsa. The card in question is the dxr3 hardware DVD player, which has analogue and SPDIF out. It currently works fine with OSS drivers. The card has no mixers, or recording function, just write and GETOPTR, SETSPEED etc function in oss. Are there any documents for alsa 09 which would outline which functions I have to implement, and what each function should do. Hopefully, this will just be a matter of adding one more file to the alsa-driver tree to support it. I can find documentation on alsa-lib, but none on how to write a low level driver for alsa-driver. Cheers James -- Nothing in this world is exactly what it appears to be. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] ALSA is in 2.5!!!
Excellent news. I am an opensource developer. My main project at the moment is xine, http://xine.sf.net and dvdnav http://dvd.sf.net. The main requirement from xine is to get audio and video in perfect sync with each other. Alsa provides for that requirement very well. I would like to say that alsa 0.9.x is a great improvement over alsa 0.5.x, and the fact that it is now in the kernel sources just goes to prove it. I found it much easier to write applications for alsa 0.9.x than alsa 0.5.x. For my part, I have only helped alsa is very minor ways. (bug fixes for SB Live) Over the coming months, I will hopefully be adding some low level audio drivers to alsa. The first on my list is dxr3 audio. This is a hardware dvd decoder with integrated analogue and spdif out. Currently, it is supported with an oss driver, but I hope to port it at some point to alsa 0.9.x. Now that alsa 0.9.x is in the kernel, there is even more reason to port over all the remaining oss drivers to alsa 0.9.x. I am finding it very difficult to find sound cards which are only supported by oss. ;-) I particularly like the way that alsa has a kernel driver module, and a separate alsa-lib. This makes the kernel image small, while at the same time presenting a very nice API to application developers. I would like to see this happen with other parts of the kernel. E.g. ISDN support. Congratulations to all the alsa developers. :-) Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis Sent: 13 February 2002 19:34 To: Jaroslav Kysela Cc: ALSA development Subject: Re: [Alsa-devel] ALSA is in 2.5!!! the big moment in ALSA existence is here. Linus integrated ALSA into 2.5 kernel tree!! The first pre-patch with ALSA will be available soon. For impatient hackers: Check http://openlogging.org, click on 'Sorted by number of lines' and choose 'Linux kernel tree' with domain 'transmeta.com' and contact 'Unknown'. I would like to send big thank you to all ALSA developers. I am looking forward to the future. sound of champagne bottles popping jaroslav, abramo, frank, takashi - you all deserve huge congratulations for your dedication and work. the future will thank you in good time. --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] ALSA is in 2.5!!!
Another nice feature of getting alsa into the kernel is that the code will then be checked with the Stanford checker. This is an intelligent checker which checks for bad pointers and generally tries to catch bugs in code even before they show themselves. It has generally improved the quality of linux kernel code, so now that alsa-driver is in the linux kernel, it will be checked as well. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Status of ALSA documentation?
As ALSA is now in the linux kernel, should the HOWTO be part of the linux documents HOWTO pages ? Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Patrick Shirkey Sent: 15 February 2002 07:35 To: Paul Davis Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] Status of ALSA documentation? --- Paul Davis [EMAIL PROTECTED] wrote: I recently showed a Mac user interested in using Linux for live stage work (no gui needed) the ALSA site so they could get some idea of progress... they just laughed and said there was _nothing_ there to help them evaluate whether ALSA (therefor Linux) was going to be useful to them... well, not within a 5 minute perusal anyway. i think this is an excellent, critical point. with ALSA's adoption into the kernel, we have both (1) a chance that more people will write HOWTOs and code but also (2) more people saying what is it? and how do i ? the current web site fails completely at both tasks. as much as i think we are still aiming for uniform operation for all cards (i.e. they just work), i think a good place to start with interface HOWTOs would be to take Dan's soundcard matrix, and add links from each card name to a HOWTO. The default set of HOWTOs can be empty, and we can add to them as time goes on. By empty, what I really mean is a boilerplate document that says if you have this type of soundcard, just do X, Y, and Z and it will work. there should also be a way to collect card-specific bug reports and accessing them all from the HOWTO page. Very good idea. The alsa-howto can easliy be linked to in this regard. Just needs a slight formatting change and a lot of tedious typing but give me a couple of months and it should be out of the way. of course a wiki would be an even better way of collecting card/setup specific quirks, but that seems a bit much to ask for right now. of course, it becomes critical that the matrix be kept up to date, which could also use a wiki-style input system. I suggest updating it once every month. Once the bulk is done it should only take about a small amount of work to add new cards. Mostly just copy and paste. --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel _ Want a new web-based email account ? --- http://www.firstlinux.net ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] 2.5.5-pre1 kernel - compile as modules?
Could this be a devfs (device filesystem) problem ? With devfs, devices appear as if by magic in the /dev directory. The old system had all devices having entries in /dev whether present or not. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duncan Sands Sent: 15 February 2002 08:34 To: Guenther Sohler Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Alsa-devel] 2.5.5-pre1 kernel - compile as modules? On Friday 15 February 2002 9:30 am, Guenther Sohler wrote: did you insmod the snd.o ??? Yes. I have /proc/asound with all entries. They just aren't readable. The soundcard is detected when I modprobe the card module (nonetheless /proc/asound/cards is not readable: no such device). I have been using the CVS and other versions of alsa with no problems, so this is presumably something to do with the kernel sound patch. Thanks for thinking about this, Duncan. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] PCM frames already played
I do this by counting how many frames have already been written(from the app), minus the frames still waiting to be written (from alsa, i.e. How many frames are still in the sound cards buffer waiting to be output.) Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Guenther Sohler Sent: 17 February 2002 10:28 To: [EMAIL PROTECTED] Subject: [Alsa-devel] PCM frames already played Is there a way to determine the number of bytes/frames already played through the DAC since last reset via snd_pcm_status in v0.9.x ? Its possible in OSS via ioctl and in alsa v0.5.0 you can view at a element bytes in sthe respective structure. But how does it work in v0.9.x ? rds guenther ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] dolby digital output
Any AC3 or DTS takes some time to decode even with an external decoder. The nice thing about them is that the standard tell us that they are fixed latency decoders. So, AC3 decoder will take a fixed amount of time to take a digital SPDIF in and convert it to 6 analogue out's for your speakers. The delay is long enough to make it not suitable for low latency applications like games and telephony. Some applications which don't care about the latency, but only care that it is predictable work ok with AC3 audio. E.G. DVD playing. The latency of decode does not matter, what matters is if we can predict the latency so we can keep audio and video in sync. If you then add an encoder, so you can mix streams, you add to the latency again. PCM is the audio amplitude sampled at fixed time periods. These samples can translated into samples in the frequency domain using the Fast Fourier Transform, thus giving the amplitude of certain frequencies at certain times. These samples in the frequency domain is what is contained in AC3. If you could mix the channels in the frequency domain instead of the PCM domain, you could save a lot of CPU time. Before: - 1) AC3 stream from DVD 2) decode to 6 PCM channel 3) Mix with other PCM source 4) 6 PCM to AC3 encoding 5) SPDIF out. 6) External decoder. 7) speakers. After: - 1) encode other PCM source into AC3. 2) mix DVD's AC3 with other sources AC3 using a frequency domain mixer. 3) SPDIF out. 4) External decoder 5) speakers. Notice that alsa just provides the SPDIF out bit, nothing else. ALSA knows nothing of AC3 or DTS. It just outputs the digital stream without modifying it. I think it would be best for your application to do the mixing. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hod McWuff Sent: 17 February 2002 06:34 To: [EMAIL PROTECTED] Subject: [Alsa-devel] dolby digital output What would be involved in enabling 5.1-channel spdif output? I'd imagine the first step would be to add an ac3 encoder, and then (possibly) the 2-5.1 channel demuxing for stereo streams. This would result in the ability to mix dolby digital streams (DVD's) with more mundane PCM streams, such as IM or telephony apps. I'm willing to tackle some moderate coding, but I haven't attacked alsa internals at all yet... where's the best docs for that? ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] dolby digital output
So all I need now, is an Digital Amp with an Ethernet port for all 6 Channel PCM, AC3 and DTS output. I already have an ethernet card for my PC and a HUB. magic.gibson.com must be stupid not to realise that what we really want is an AMP with an Ethernet port, not yet another sound card. We could then just connect the AMP to the ethernet port on any PC, and have perfect digital quality output. Alsa would then not be needed, because once the audio is in packets, it would be better to keep it that way in the application. One could even use Radio Lan technologies, and thus remove all the cabling as well. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bob Ham Sent: 18 February 2002 14:51 To: James Courtier-Dutton Cc: [EMAIL PROTECTED] Subject: RE: [Alsa-devel] dolby digital output On Sun, 2002-02-17 at 18:44, James Courtier-Dutton wrote: A simple 100 Megs Full duplex point to point Ethernet cable can handle just about anything S/PDIF, USB, SCSI, IDE can throw at it. I assume you've seen http://magic.gibson.com/? Bob -- Bob Ham: [EMAIL PROTECTED] My music: http://mp3.com/obelisk_uk GNU Hurd: http://hurd.gnu.org/ Do your bit for UK drugs law reform: http://www.angeldeclaration.com/ A pessimist expects the weather to get worse. An optimist hopes it will improve. A realist adjusts the sails. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] dolby digital output
The magic web site did not mention anything about an AMP. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bob Ham Sent: 18 February 2002 16:27 To: James Courtier-Dutton Cc: ALSA Development Mailing List Subject: RE: [Alsa-devel] dolby digital output On Mon, 2002-02-18 at 15:46, James Courtier-Dutton wrote: magic.gibson.com must be stupid not to realise that what we really want is an AMP with an Ethernet port Umm.. this *is* what magic can provide. A guitar with a an ethernet port, an amp with an ethernet port, a mixer with an ethernet port, a computer with an ethernet port.. you name it. (And when I say ethernet here, I mean RJ45.) Has the following specs: 32 channels @ 44.1 kHz x 32 bits 32 channels @ 48 kHz x 32 bits 16 channels @ 96 kHz x 32 bits 8 channels @ 192 kHz x 32 bits This is over one cable; it's not a network in the sense of ethernet. You can't plug all your instruments into a 100baseTX hub, unfortunately, but you can plug all your instruments into NICs in the back of your computer. -- Bob Ham: [EMAIL PROTECTED] My music: http://mp3.com/obelisk_uk GNU Hurd: http://hurd.gnu.org/ Do your bit for UK drugs law reform: http://www.angeldeclaration.com/ A pessimist expects the weather to get worse. An optimist hopes it will improve. A realist adjusts the sails. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] audio via ethernet (was: dolby digital output)
I think it is very interesting hearing what peoples views are when comparing current digital audio technologies like SPDIF and packet based technologies like ethernet for digital audio. Very few people have in depth knowledge of what is possible with both technology. Some people have in depth knowledge of SPDIF and sample sync etc. Other people have in depth knowledge of packet technologies. I will keep watching this thread to see where it goes. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of stef Sent: 18 February 2002 23:01 To: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] audio via ethernet (was: dolby digital output) Bob Ham wrote: If it's possible for me to synchronise my PC clock to sub-millisecond accuracy over *IP* on a LAN, I somehow doubt it'd be impossible to synchronise word clocks over ethernet. Sounds great! 20 nanoseconds would be enough. But the problem in digital audio is that the clock has to be readjusted in short intervals. Anyway, which software/protocol/service do you use for your clock synchronisation? _very_ interesting! Thanks, Stef(an). ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] hello?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott Jonathan Sent: 25 February 2002 02:39 To: [EMAIL PROTECTED] Subject: [Alsa-devel] hello? I have several times tried to erase my email address from this list, but it keeps telling me my email address is not found. Yet I keep receiving emails! Please erase my address from this list! Thanks! JS _ $B%a!<%k$@$1$8$c$J$+$C$?!*%$%s%?!<%M%C%HJXMx%5!<%S%9$,$R$H$^$H$^$j(B http://explorer.msn.co.jp/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel See Go to that URL. At the very bottom box(edit options) put your email address in. All you have to do then is click "edit options" and then the next page is easy. Just put your password in the first box, and click "Unsubscribe" Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] AC3 Passthru on SB Live
Hello AC3 passthru on the SB Live does not seem to work on all platforms with the latest alsa-cvs. (26-2-2002) It works on my system, which is a SB Live Rev 6, which only started working recently. It does not work on a SB Live rev 7 (I don't have this, but others have reported.) Can anyone comment on which SB Live revisions work, and which do not. All the SB Live versions seem to work with the emu10k1 kernel drivers. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] RE: AC3 Passthru on SB Live
As a small extra, the emu10k1 kernel driver which support oss, has a few bits of info which might be of help From the emu10k1 linux kernel developers: - We allocate memory with pci_alloc_consistent() which according to DMA-mapping.txt assures 32-bits PCI addresses. On top of that we set a dma_mask (with pci_set_dma_mask) of 29 bits (512Mib). Also: - 29 bit (512MiB), mostly speculation/trial-and-error though. See main.c and the pci_set_dma_mask() calls. Does this help alsa09 at all ? Cheers James -Original Message- From: James Courtier-Dutton [mailto:[EMAIL PROTECTED]] Sent: 27 February 2002 15:51 To: [EMAIL PROTECTED] Subject: AC3 Passthru on SB Live Hello AC3 passthru on the SB Live does not seem to work on all platforms with the latest alsa-cvs. (26-2-2002) It works on my system, which is a SB Live Rev 6, which only started working recently. It does not work on a SB Live rev 7 (I don't have this, but others have reported.) Can anyone comment on which SB Live revisions work, and which do not. All the SB Live versions seem to work with the emu10k1 kernel drivers. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Timer?
-Original Message- From: Paul Davis [mailto:[EMAIL PROTECTED]] Sent: 06 March 2002 17:27 To: James Courtier-Dutton Cc: Ulrich Zadow; [EMAIL PROTECTED] Subject: Re: [Alsa-devel] Timer? The delay value is calculated from getting the amount of samples still in the sound buffer. See the ao_alsa_delay function is xine-lib/src/audio_out/audio_alsa_out.c So if the delay is 100 ms. You have to place samples in the audio buffer 100ms before you wish to hear them. Not quite right. You have to put the samples in the buffer when its time to put them there. The audio interface will tell you when its time to do that by sending you an interrupt, which in POSIX terms means your app will wake up from poll(2) if it was waiting on the relevant file descriptor(s). You can then deliver the data. Our app does not use poll or anything like it. It does not get woken up by the audio device. Look at our source code. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] ALSA vs OSS/free
As a programmer, alsa is just much easier to use. alsa provides a consistent api interface for all sound cards thanks to the alsa-lib. (shared user space code) So, if I write an app for my sound card, I can be pretty sure the app will work on all other sound cards. With OSS/Free, hardly any of the drivers support all the OSS api features, so the application has to do work arounds if certain api features are not present. To me that is messy. Alsa should always be considered as a low level driver to drive the hardware and nothing more. Then one can put ardour and jack on top, for extra features. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kai Vehmanen Sent: 07 March 2002 13:56 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Alsa-devel] ALSA vs OSS/free Why is ALSA the better alternative? That's a question I've been asked quite a few times recently. Below is a reply I just wrote to ecasound-list. I'd be very interested in hearing your comments on this issue. Have I missed some important points? One thing that seems be causing a lot of confusion is performance and latency comparisons. While ALSA provides many things that make it easier for developers to reach better performance and low latency, similar results can be achieved with well-written OSS drivers and applications. Only in few specific cases (multichannel noninterleaved soundcards, etc) ALSA provides a clear advantage. From marketing point of view I think it's wise to acknowledge this. But there are other reasons why future looks bright for ALSA: --cut-- Philosophically (and technically) speaking, are there real advantages for me to install alsa (other than the above) when OSS/free works for me? I If OSS works for you, then no. ALSA's primary advantages are: [common] - separation of kernel and user-space code [all] - ALSA library can provide more functionality to applications (format conversions, sharing soundcard resources, dsp plugins) - benefits ALSA-native apps [alsa-kernel/alsa-driver] - better driver architecture - more shared code between drivers for different soundcards - fixes and improvements to common code affect all drivers - drivers behave more uniformly - benefits both ALSA-native and apps using OSS-emulation - support for pro-level soundcards without performance problems - for instance handling devices that only support noninterleaved buffer layout - befefits ALSA-native apps (and in some cases also apps using OSS-emulation) [alsa-lib] - better API for applications [alsa-lib] - more flexible configuration of various parameters - well-designed API for acquiring realtime status information (for various playback/capture synchronation purposes) - benefits ALSA-native apps So shortly put, ALSA provides a better framework for writing drivers and for developing audio applications. When comparing OSS/Free and ALSA from an end-user's point of view, it comes down to the quality of the drivers for the soundcard type in question, and the specific applications that are used. Some OSS/Free drivers are very good and support all OSS API features. If this is the case and all apps seem to work ok, you don't have much to gain from switching to ALSA... yet. But because of the abovementioned reasons, over time ALSA drivers and applications will become better than OSS versions. I think this is inevitable. --cut-- -- http://www.eca.cx Audio software for Linux! ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] ymfpci : four speakers with OSS-emulation ?
Why not just change the app to support alsa 0.9.x. alsa 0.9.x is now in kernel 2.5.x, so the app should really move to supporting it anyway. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Xavier ALLAMIGEON Sent: 12 March 2002 21:11 To: [EMAIL PROTECTED] Subject: [Alsa-devel] ymfpci : four speakers with OSS-emulation ? Good evening, I have installed the alsa-driver0.9.0beta12 on my MDK8.1 (kernel 2.4.18), and my rear speakers work. For example with aplay -Dhw:0,2 foo.wav. Is this possible to use the four speakers together under alsa or under the OSS emulation, with a sound card based on the ymfpci modules ? I know it works with a SBLive!. Besides, I have seen that there are interesting configuration files in /usr/share/alsa. What must I do if I want the changes of these files to take effect ? Thanks for all ! ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] ymfpci : four speakers with OSS-emulation ?
try alsaplayer -Dsurround40 foo.mp3 That works on a sb live. Cheers James -Original Message- From: Adam K Kirchhoff [mailto:[EMAIL PROTECTED]] Sent: 13 March 2002 14:26 To: James Courtier-Dutton Cc: Xavier ALLAMIGEON; [EMAIL PROTECTED] Subject: RE: [Alsa-devel] ymfpci : four speakers with OSS-emulation ? On Wed, 13 Mar 2002, James Courtier-Dutton wrote: What command line do you use for aplay, alsaplayer. $ alsaplayer foo.mp3 Will play on the front speakers. $ alsaplayer -Dhw:0,2 foo.mp3 Will play on the rear speakers. I had almost this exact same conversation on this mailing list last month and we came to the conclusion that there is no way to get the output to default to both the front and rear speakers with the current setup. Adam For the device name, you can use default, front, rear and surround40 with a SB Live.(The card I have.) instead of plug:0,0 or similar. What device names do you use for the ymfpci ? Cheers James -Original Message- From: Adam K Kirchhoff [mailto:[EMAIL PROTECTED]] Sent: 13 March 2002 13:58 To: James Courtier-Dutton Cc: Xavier ALLAMIGEON; [EMAIL PROTECTED] Subject: RE: [Alsa-devel] ymfpci : four speakers with OSS-emulation ? Well, the ymfpci driver (with native Alsa support) only uses the front speakers by default, unless the application (ie. aplay, alsaplayer) is told the use the rear speakers. In either case, you can still only get output on either the front or the rear :-) So rewriting the application wouldn't necessarily solve the problem. Even if that wasn't the case, and rewring the application did resolve the issue, it doesn't really do the end user any good if they have to wait around for every application (some of which may now be unsupported) to be rewritten to support Alsa natively :-) Adam On Wed, 13 Mar 2002, James Courtier-Dutton wrote: Why not just change the app to support alsa 0.9.x. alsa 0.9.x is now in kernel 2.5.x, so the app should really move to supporting it anyway. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Xavier ALLAMIGEON Sent: 12 March 2002 21:11 To: [EMAIL PROTECTED] Subject: [Alsa-devel] ymfpci : four speakers with OSS-emulation ? Good evening, I have installed the alsa-driver0.9.0beta12 on my MDK8.1 (kernel 2.4.18), and my rear speakers work. For example with aplay -Dhw:0,2 foo.wav. Is this possible to use the four speakers together under alsa or under the OSS emulation, with a sound card based on the ymfpci modules ? I know it works with a SBLive!. Besides, I have seen that there are interesting configuration files in /usr/share/alsa. What must I do if I want the changes of these files to take effect ? Thanks for all ! ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] some bits about cirrus 46xx: from LKML
It is a shame that this person is really missing the point of what the open source community really wants. Good technical documentation, so that the open source DSP audio engineers around the world can write a good 46xx driver for Linux. We really don't need cirrus audio engineers, we just need good technical documentation on the DSP. E.g. Instruction sets, registers, assemblers, dis-assemblers, current source code for the DSP static images. If cirrus don't support or sell the product any more, what is the reason for not giving out this information. Cheers James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andrea Venturi (personale) Sent: 16 March 2002 11:47 To: [EMAIL PROTECTED] Subject: [Alsa-devel] some bits about cirrus 46xx: from LKML FYI: i didn't see this email on ALSA-DEVEL, so i'm posting here too.. don't know if useful to anyone.. but it's a real pity to see the cirrus dsp couldn't be exploited to its real power by lack of a single cirrus people! :-( bye andrea venturi From: Woller, Thomas [EMAIL PROTECTED] To: 'David Ford' [EMAIL PROTECTED], Woller, Thomas [EMAIL PROTECTED], linux-kernel [EMAIL PROTECTED] Subject: RE: 2.4.3+ sound distortion Date: Wed, 6 Mar 2002 10:43:53 -0600 david, et al a) i am very sorry about the tinny sound you are experiencing. we no longer have any DSP pc audio engineers working at cirrus, and pc audio products are no longer developed or supported here at cirrus. i have talked this problem over with the only person that might help, and the debugging effort involved is extensive and may not yield results. we do not fully understand the issue, but believe that several internal points in the DSP become misaligned resulting in the tinny sound. b) the static DSP image that is currently used with the linux cs46xx driver, is not capable of any of the fancy extensive feature set, and the work involved would require an engineer with intimate knowledge of the DSP which no longer is present. c)see b d) i am always willing to assist the linux effort, it's just difficult due to the lack of any support at cirrus for pc audio any longer. i am working on embedded RTOS in my official job, but always try to fix any linux pc audio related bugs as i am able. also, without any DSP engineers we can not create another static DSP image with the additional tasks necessary to take advantage of the wonderful features of cards with the cs46xx controller. we are stuck with the current DSP images that are available. there is a small glimmer of light concerning secondary codec support and SPDIF support. i had found 2 other test static DSP images that might be useful. i placed 2 piles of code out on a cirrus ftp site (see below). the first is a cs46xx driver with an untested static DSP image that snoops the data to the primary codec and pumps it to the secondary, so that there is sound coming from the rear speakers, although the same as the the front. the second pile of code (EOLT) contains a set of tests that we used for testing the cs4630. the static image used in these tests contained in this directory functioned with SPDIF in/out. i am unsure whether the other tasks are loaded in this image to support the general audio data paths, so this static image may not support more than spdif. i tried using the static spdif image on the latest cs46xx linux driver, but it did not work with a simple static image replacement in the source. specific problem definition and resolution using the spdif EOLT static image with the linux cs46xx sources, has not been determined. anyone and everyone are welcome to look over these 2 piles of source, but my time is very limited concerning any new development for spdif and/or secondary codec. here is the ftp site info. the cs46xx code is based on an older version of the 2.4 kernel. server: ftp1.cirrus.com login: ftppclink password: cSPxQMd thanks Tom Woller ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Migration from 0.5 to 0.9?
Leif Lindholm wrote: Hello I'm working on a set-top-box based on the National Semiconductor SC1200 Geode integrated microprocessor. National have been nice enough to write an Alsa-driver for the built-in AC97-controller/audio thingy - unfortunetaly it is written for 0.5.10b. So now I need to modify this one to use with 0.9. Can someone give me a few tips/hints or is there possibly a document about this that I failed to google up? regards / Leif ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel I would post the source code of your current driver somewhere (URL). If the set top box uses the AC97-Controller, alsa09 might already have a sound driver for it, but someone might need to add an extra bit of card recognition code to get it to work. Also, if you can post to a URL any documents about the set-top-box, which would make it easier for people to help you. We might be able to recognise which of the current drivers is closest to it from that. It would probably be better to get support for the set top box into the publically available version of alsa09, so that it will be kept up to date with any other changes which might happen in alsa without you having to worry about it. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Migration from 0.5 to 0.9?
Leif Lindholm wrote: On Fri, 2002-04-05 at 04:00, James Courtier-Dutton wrote: I would post the source code of your current driver somewhere (URL). If you still think so after reading this mail (especially license stuff at end of mail), I could post a diff somewehere. If the set top box uses the AC97-Controller, alsa09 might already have a sound driver for it, but someone might need to add an extra bit of card recognition code to get it to work. It uses the internal AC97-controller of the SC1200 processor (XpressAUDIO - PCI device 100b:0503). I didn't find anything like that in the 0.9 code when I browsed through it. The driver also incorporates some MIDI stuff and such. Also, if you can post to a URL any documents about the set-top-box, which would make it easier for people to help you. We might be able to recognise which of the current drivers is closest to it from that. Well - I'm _paid_ to write these drivers :) National puts Confidential notices on all their documentation, so I don't think it would be a good idea to post those... And since our box is not quite on the market yet, I think my managers might not like me releasing too much specs. So what I can say is about this: The audio controller is described pretty well in this message I located on google: http://www.alsa-project.org/archive/alsa-howto/msg00312.html Different revisions of the box use CS4299 or CS4205 codecs. It would probably be better to get support for the set top box into the publically available version of alsa09, so that it will be kept up to date with any other changes which might happen in alsa without you having to worry about it. I definitely agree with you about this, however Nationals driver has some weird BSD with export restrictions license attached to it. Personally I think they should release the code under GPL so that it can be integrated with the main project, and I will try to convince them to do so - but for now I simply don't have time to wait for that. To clarify myself: what I really need right now is some hints about what differs between 0.5 and 0.9 from the driver(programmer)s point of view. regards / Leif I guess you might be out of luck then, as there is currently no documentation on how to write sound card drivers for alsa09. I think the only way you can possibly compare alsa05 with alsa09 at the moment, is pick simple sound card like the sb16, and compare the card's source code in alsa05 and alsa09. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Migration from 0.5 to 0.9?
Eric Dantan Rzewnicki wrote: James Courtier-Dutton wrote: Leif Lindholm wrote: On Fri, 2002-04-05 at 04:00, James Courtier-Dutton wrote: I guess you might be out of luck then, as there is currently no documentation on how to write sound card drivers for alsa09. I think the only way you can possibly compare alsa05 with alsa09 at the moment, is pick simple sound card like the sb16, and compare the card's source code in alsa05 and alsa09. Cheers James I know this information is about writing an alsa client and not a driver But, perhaps Mark Rages', Matthias Nagorni's and Paul Davis's pages on writing clients with the alsa library would be helpful in some way: http://mlug.missouri.edu/~markrages/wiki/index.php?WritingAnAlsaClient The later two are linked to from the first. I appologize if this isn't helpful. -Eric Rz. I think Leif was asking how to write drivers for the sound hardware device to alsa-lib interface(i.e. What alsa-driver/alsa-kernel does) and not the application to alsa-lib interface. Maybe I will write some documentation when i attempt to write a new hardware driver myself. I am thinking of writing one for the dxr3 mpeg2 decoder board, which has a simple audio out jack on it, which currently only have oss support. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] alsa09 sound for portable computers
Takashi Iwai wrote: Hi James, At Thu, 04 Apr 2002 21:55:50 +0100, James Courtier-Dutton wrote: Hello I have just managed to get alsa09 sound to work on my portable after a lot of difficulty with neither alsa or oss modules loading. I would like to suggest that we start adding an alsa09 howto for Portable PC users. It would have: - Name of PC, sample modules.conf line to use. My old portable is a Toshiba Satellite 4010CDT which is NOT plug and play sound. could you try my (updated) alsaconf script for test? it's written for suse distribution, but should run on any system with pciutils and dialog. the file is found at ftp://ftp.suse.com/pub/people/tiwai/alsa9-packages/misc/alsaconf just run it as root, choose probe legacy isa chips, then choose opl3sa2 from the list. ciao, Takashi The sound card was a non-plug and play sound card, so I don't think any current alsaconf file will help. For example, the howto for my card would be: - Go into the BIOS, get the IO and IRQ settings of the sound card. Enter those IO and IRQ settings in the modules.conf alias file together with -isapnp=no. Then it will work. I did not know before I started that if the alsa-driver modules are compiled with isapnp switched on. You cannot use non-plug and play sound cards, without specifically telling the modules.conf alias line that it is a non-pnp device. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Migration from 0.5 to 0.9?
Takashi Iwai wrote: At 04 Apr 2002 15:41:36 +0200, Leif Lindholm wrote: Hello I'm working on a set-top-box based on the National Semiconductor SC1200 Geode integrated microprocessor. National have been nice enough to write an Alsa-driver for the built-in AC97-controller/audio thingy - unfortunetaly it is written for 0.5.10b. So now I need to modify this one to use with 0.9. Can someone give me a few tips/hints or is there possibly a document about this that I failed to google up? unfortunatley (as always :) there is no documentation about the kernel stuff yet. since you have already a working 0.5.x driver, it's not too difficult, though. as far as i can remember.. - renaming fragment - period channel - stream voice - channel snd_pcm_subchannel - snd_pcm_substream - renaming of constants generally: SND_XXX - SNDRV_XXX some other changes, too: e.g. SND_PCM_TRIGGER_GO - SNDDRV_PCM_TRIGGER_START - snd_assert() is used instead of snd_debug_check() (note that the argument is opposite, assert(x) means that x is true .) - no longer difference of stream/blocking modes - general hardware information is stored in snd_pcm_hardware_t and passed to the runtime struct in open(). the information is intuitive, look at other sources. - abstracted ops. open(substream) - open the device - copy the substream-runtime-hw parameter (not pass the pointer) - set up the constraints (if any) hw_params(substream, hw_params) - allocate a buffer usually via snd_pcm_lib_malloc_pages prepare(substream) - set up the hardware parameters (like 0.5.x) note that parameters in runtime struct are stored in frames, not in bytes. there are functions, snd_pcm_lib_buffer_bytes() and snd_pcm_lib_period_bytes() trigger(substream, cmd) - start, stop, pause (like 0.5.x) pointer(substream) - returns the current pointer where the hw refers. (in frames!) hw_free(substream) - free the buffer usually via snd_pcm_lib_free_pages(substream) close(substream) - close the device, clean up. copy, silence - needed only if you don't (can't) use mmap. they are defiend in snd_pcm_ops_t struct and set up in pcm initizliation routine via snd_pcm_set_ops(). - when the interrupt occurs at period (fragment), call snd_pcm_period_elapsed(substream) just once per interrupt. - no longer snd-xxx functions for allocating port, dma and irqs. you need to use standard functions. for releasing struct resources *, you have to use kfree_nocheck() to avoid malloc-wrapper. - definitions of pci id table, probe(), remove() (suspend() and remove() if possible) on struct pci_driver. - finally and best way - look at drivers on a same chip of both 0.5.x and 0.9.0, and compare them :) Takashi This is a very good start at some documentation! In case Leif does not understand the concept of a frame, here is what I understand by it. Audio stream is 16 bit samples, 2 channels = 4 bytes (2 bytes of each sample, and 2 channel=2*2) = 1 frame Audio stream is 16 bit samples, 6 channels = 12 bytes = 1 frame Audio stream is 8 bit samples, 2 channels = 2 bytes = 1 frame So, no matter what the sample bits, or number of channels, there is always 1 frame. If the stream is 48000 Hz, it will contain 48000 frames. If the stream is 44100 Hz, it will contain 44100 frames. If the stream is 48000 Hz, 16 bit samples, 6 channels 5.1(surround) audio, it will contain 48000 frames. Hopefully, by these examples, you get an idea of what a frame is. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [alsa-cvslog] CVS: alsa-kernel/pci/emu10k1 emu10k1_main.c,1.12,1.13
Takashi Iwai wrote: Update of /cvsroot/alsa/alsa-kernel/pci/emu10k1 In directory usw-pr-cvs1:/tmp/cvs-serv9192 Modified Files: emu10k1_main.c Log Message: fixed default mask values (these change won't affect the actual behavior, though) Index: emu10k1_main.c === RCS file: /cvsroot/alsa/alsa-kernel/pci/emu10k1/emu10k1_main.c,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- emu10k1_main.c 13 Mar 2002 19:49:38 - 1.12 +++ emu10k1_main.c 8 Apr 2002 12:20:36 - 1.13 -630,9 +630,9 emu-fx8010.fxbus_mask = 0x303f; if (extin_mask == 0) - extin_mask = 0x1fcf; + extin_mask = 0x3fcf; if (extout_mask == 0) - extout_mask = 0x3fff; + extout_mask = 0x1fff; emu-fx8010.extin_mask = extin_mask; emu-fx8010.extout_mask = extout_mask; This seems to have fixed AC3 Passthru mode on SB Live (rev 7) cards. Just so you know, all SB Live cards worked before for AC3 Passthru except the rev 7 cards. I just got a report on the xine-user list about it. Ok, so you did not know you were fixing it, but well done anyway ;-) Cheers James
Re: [Alsa-devel] Update on website.
Patrick Shirkey wrote: Forgot the crucial part :) http://www.alsa-project.org/index-new.html -- Patrick Shirkey - Boost Hardware Ltd For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.boosthardware.com/LAU/Linux_Audio_Users_Guide/ It would be even nicer if that link actually worked. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] alsa-conf will not compile
Hello
I just got the latest alsa 0.9.x cvs (as of about 5 mins ago)
Everything compiles fine, except alsa-conf
I enclose stdout and stderr output from the ./cvscompile command.
Cheers
James
`/usr/share/automake/install-sh' - `./install-sh'
`/usr/share/automake/ylwrap' - `./ylwrap'
`/usr/share/automake/mkinstalldirs' - `./mkinstalldirs'
`/usr/share/automake/missing' - `./missing'
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for bison... (cached) bison -y
checking for gcc... (cached) gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for c++... (cached) c++
checking whether the C++ compiler (c++ ) works... yes
checking whether the C++ compiler (c++ ) is a cross-compiler... no
checking whether we are using GNU C++... (cached) yes
checking whether c++ accepts -g... (cached) yes
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... (cached) yes
checking for ranlib... (cached) ranlib
checking for SLcurrent_time_string in -lslang... (cached) yes
checking for Gpm_Close in -lgpm... (cached) no
checking how to run the C preprocessor... (cached) gcc -E
checking for ANSI C header files... (cached) yes
checking for slang/slang.h... (cached) no
checking for slang.h... (cached) yes
checking for newt.h... (cached) yes
checking for working const... (cached) yes
checking for size_t... (cached) yes
creating ./config.status
creating Makefile
creating newt/Makefile
creating config.h
config.h is unchanged
cd . autoheader
make all-recursive
make[1]: Entering directory `/usr/local/alsacvs/alsa-conf'
Making all in newt
make[2]: Entering directory `/usr/local/alsacvs/alsa-conf/newt'
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c newt.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c button.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c form.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c checkbox.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c entry.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c label.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c listbox.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c scrollbar.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c textbox.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c scale.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c grid.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c windows.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c buttonbar.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/slang-g -O2 -c checkboxtree.c
rm -f libanewt.a
ar cru libanewt.a newt.o button.o form.o checkbox.o entry.o label.o listbox.o
scrollbar.o textbox.o scale.o grid.o windows.o buttonbar.o checkboxtree.o
ranlib libanewt.a
make[2]: Leaving directory `/usr/local/alsacvs/alsa-conf/newt'
make[2]: Entering directory `/usr/local/alsacvs/alsa-conf'
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c Alloc.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c Def.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c Device.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c Devices.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c Expr.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c Field.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c Fields.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c Functor.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c Module.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c Modules.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c Param.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c Params.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c ParamDef.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c
ParamDefs.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c PValue.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall -ftemplate-depth-20 -c PValues.cc
c++ -DHAVE_CONFIG_H -I. -I. -I. -I./newt-g -Wall
Re: [Alsa-devel] Pause and Resume testing needed
James Courtier-Dutton wrote: Hello Are there any test applications which test the pause/resume functionallity. I have an app which is calling pause, then resume, but after resume, the sound is very choppy. I was hoping that there was an application out there which already worked with pause/resume so I can narrow down the problem to alsa or my application. Cheers James I found out what is wrong with my pausing problem. It is an alsa bug. I have a SB Live. pausing and resuming works fine in all modes except AC3 passthru. If one paused an AC3 passthru stream, it becomes very jumpy. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [alsa-cvslog] CVS: alsa-kernel/pci/emu10k1 emu10k1_main.c,1.12,1.13
Markus Plail wrote: Hi Takashi! * Takashi Iwai writes: Markus, could you try the latest cvs version, which fixes the real behavior, whether digital out works? if it doesn't work again, then definitely GPOUT0 is the spot. It doesn't work with latest CVS. looking at OSS source codes, i found GPOUT0 is necessary only for 5.1 cards (and seems for Audigy too - i need to fix again). so i'm not sure whether we can determine it from revision number. Someone should test if the version which is doing fine here, is also OK on other revisions of the card, so 'we' could just leave the 'else statement' away. James has a rev06 to check it, for example. Regards Markus There are several different versions of the SB Live. My SB Live rev06 is not a SB Live 5.1, so it has 2 audio stereo output jacks, one for front, one for rear, and then a spdif jack. The spdif jack is not switchable between analogue and digital. It is fixed at digital. Maybe the rev07 card is a SB Live 5.1, which has a switchable digital/analogue spdif jack, so it can output on 3 analogue stereo jacks, or with a switch (maybe GPOUT) it changes the 3rd analogue out jack into an spdif digital only jack. Does this info help at all? Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [alsa-cvslog] CVS: alsa-kernel/pci/emu10k1 emu10k1_main.c,1.12,1.13
Takashi Iwai wrote: There are several different versions of the SB Live. My SB Live rev06 is not a SB Live 5.1, so it has 2 audio stereo output jacks, one for front, one for rear, and then a spdif jack. The spdif jack is not switchable between analogue and digital. It is fixed at digital. does Digital/Analog Jack switch affects the behavior on your digital jack? i guess it doesn't. if it doesn't affect, then we can switch this bit safely on all cards. Takashi My SB Live (non 5.1) does not have a Digital/Analog Jack, it just has a Digital Jack, so I would prefer that the Digital/Analogue Switch in alsamixer was removed for rev06 cards and below, but present for rev7 cards and above. Currently, toggling the alsamixer Digital/Analogue Switch has no effect what so ever. I think this rev07 passthru issue might have been the user just not knowing about the Digital/Analogue switch in alsamixer. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [alsa-cvslog] CVS: alsa-kernel/pci/emu10k1 emu10k1_main.c,1.12,1.13
Markus Plail wrote: Hi James! * James Courtier-Dutton writes: I think this rev07 passthru issue might have been the user just not knowing about the Digital/Analogue switch in alsamixer. NO! I have been knowing about it all the time. And as I wrote to Takashi this had/has nothing to do with my problem. The switch worked, but AC3 wasn't passed through, so this is surely not the readon. I wouldn't have gotten any sound then, or better only digital enabled sound, because the preset is digital sound 'ON'. Regards Markus Plail Sorry, it was only an idle thought. Maybe the Digital/Analogue switch never worked until now. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [linux-audio-dev] Re: [Alsa-devel] ALSA homepage redesign
Joern Nettingsmeier wrote: James Courtier-Dutton wrote: ... I think we should have a section on the web site for the different applications which support different alsa versions. N. could we please please please annihilate every last little trace of alsa 0.5.x from that page ? if that's the stable release, people should be using kernel 1.2 on an 8086 (as everyone knows, that's the stable release of the pentium). if it has to be, add a very small link to *OBSOLETE* releases and apps that use them, but please not on the front page. i don't know how often i have told newbies who had just freshly installed stable to ditch it and start over with 0.9... i don't see why jaroslav has sticked to this stable/unstable naming scheme so long, but probably he had too many other things to do. patrick, please fix this asap. set_rant_mode(off); really like the new site. good to see it maintained, and the three main links for different interest groups are an excellent idea. jrn I agree with you. The web site currently only mentions applications compatible with alsa 0.5.x There is no mention of 0.9.x at all in the applications section. If alsa follows ISO9000 release numbering guidelines, the full, non beta release should be called 0.10.x Apparently you should not have beta 0.9.x and then go to full release 0.9.x, apparently one should go to 0.10.x for the first non-beta release, and then only have bug fixes updating 0.10.x. Maybe that is why the linux kernel follows this pattern. Developement 2.3.x, release 2.4.x, development 2.5.x, release 2.6.x Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] too many alsamixer sliders
Maarten de Boer wrote: Hello, Updating my fltk alsamixer frontend, alsamixergui, I once again found that alsamixer (and therefore alsamixergui) shows a lot of sliders. With my Audigy, it's really too much. I think it would be very nice to be able to configure alsamixer, to show only a subset of sliders. I guess a .alsamixerrc file in the users homedirectory. But maybe the /etc/asound.state could be used for that as well? It would be nice to have several presets or groups.. Do you have any suggestions about how to do this? I would not mind implementing it (I think it's won't be to much work), but I'd like to have your opinion first. Maarten Maybe having a key in alsamixer to switch between playback and capture sliders groups. Currently, playback and capture sliders are side by side, creating a rather long line of sliders. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: About integer64
Paul Davis wrote: Not very much: a) if 32 bit integer could be enough expressive, what's the problem to truncate it in your driver? if i knew that this was true, i would do so. i don't know that. the rms meters are the *only* registers on the h-dsp that are 64 bit, so i assume there is some reason for this. b) if a 32 bit integer is not enough and a float is preferrable: considered that an ieee754 floating point is in the form (1+man)*2^exp what's the problem in converting it in your driver using ffs and some shift? if the lkml crew see us using floating point in any form in the kernel, we will attract complaints, even if we use integer operations to do so. i am firmly convinced of this. With both way I don't see the two point you make: 1) why bother with signed vs unsigned for purity abramo! for purity! 2) why use 64 bit integer Of course if a 64 bit integer is the best way to represent/report the value all is fine, but in this case I doubt that you don't have available the 64th bit for the sign. that seems likely to me also. i suspect we have somewhere between 32 and 64 bits of information. i didn't say that i conclusively needed the sign bit - i was noting that the current API doesn't make unsigned values possible. What is wrong with useing floats in the alsa-lib, and then casting them to uint64 for all calls to the kernel. That way, the kernel only ever sees a uint64, but the application sees a nice float. Cheers James ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] alsa-conf will not compile.
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 ? Cheers James --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Suggestion: Multichannel enharnacements to alsa-lib.
Hello It would be nice if there was a feature in alsa that would let the user tell alsa which speakers are plugged into which sound card sockets. E.g. On sound card 0, I have: - Left speaker in Stereo Jack 1-Left Right speaker in Stereo Jack 1-Right Rear Left in Stereo Jack 2 - Left Rear Right in Stereo Jack 2 - Right Center in Stereo Jack 3 - Right LFE in Stereo Jack 3 - Left. This would tell alsa-lib that if it was sent 5.1 channel audio, it would not change it. If it was send 2-channel PCM, it would up-mix it using the dolby 2-4 channel sound method and also generate the Center and LFE channels. If the user did not have 6 speakers, they could tell alsa :- Left speaker in Stereo Jack 1-Left Right speaker in Stereo Jack 1-Right LFE in Stereo Jack 2 - Left. alsa-lib would then accept 6 channels from the user's application and automatically downmix it for the 3 speakers the user had. The user could also have 2 sound cards, with Front speakers on one sound card, and rear speakers on another sound card. Another feature for alsa-lib could be adding volume and delay controls in. For example, the user might want to adjust the volume of the LFE without changing the volume of the other channels. Also, depending on where the speakers are in the room, the user might want to add certain delays to certain channels so that the sound is in sync when it gets to the user's ears. The reason I think that this would be good to have in alsa-lib is so it would only have to be implemented once, and then all audio applications could use the features. I am currently helping to write a media application in linux that plays DVDs that have 5.1(e.g 6 channels) audio tracks. It would be nice if my audio application did not have to care about what speakers the user has, and just output 6 channels every time and let alsa-lib adjust. Also, if I used another audio application that could play CD-Digital Audio, alsa-lib could automatically upmix it to 5.1 using dolby surround 2-4 upmix, and alsa-lib could then fill in the center and lfe channels. This way, all the current linux applications that use ALSA would not have to be changed, but the user would get much better sound output as alsa-lib would convert the sound to make full use of the users speaker layout. Supported speaker formats needed are: - 1) Center (Mono) 2) Front Right, Front Left. (Stereo) 3) Front Right, Front Left, Center (3 Channel front.) 4) Front Right, Front Left, LFE (3 channel front/LFE) 5) Front Right, Front Left, Rear Right, Rear Left (4 channel front/rear) 6) Front Right, Front Left, Center, Rear Right, Rear Left (5 Channel front/rear/center) 7) Front Right, Front Left, Rear Right, Rear Left, LFE (5 Channel front/rear/LFE) 8) Front Right, Front Left, Center, Rear Right, Rear Left, LFE (6 channel 5.1) 9) Future setups with maybe 7,8 or 9 speakers for home real cinema setups. DTS 6.1 etc. Cheers James --- 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] Audiophile 2496 S/PDIF Support
Robert Robinson wrote: Takashi, I had communication from Kysela Jaroslav indicating that the Audiophile 2496 driver does support digital I/O. The problem may be that I have not been using an audio interface program that supports the digital option. This choice is never displayed as part of the I/O. Robbie I own a SB Live card, and not an Audiophile 2496, but on the SB Live you use alsamixer to select all the recording sources. Then you run arecord and it records the sound from the multiple sources mixed together. The problem with the SB Live is that recording from the SPDIF is always interpolated to 48kHz, some interpolation happens between 48Khz input and the 48Khz of the sound card. In reality the sound quality does not change, but it does cause problems if you are trying to capture an AC3 or DTS signal, because the interpolation breaks it. A good program to test recording in is arecord, which comes with alsa. Cheers James --- 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] Multiple Audio Streams
There are other applications/tools you can use, one of which is JACK that allows for multiple audio streams mixed in software and lots of other cool stuff. Cool, I'll see if I can find some information about that. I hadn't heard of it before... is it GPL'd? Rob http://jackit.sourceforge.net/ Cheers James --- 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] Problems with snd_pcm_status_get_delay()
Hello Can someone please explain to me the use of snd_pcm_status_get_delay() If a buffer size is 16384, and avail=6384, should delay therefore equil 1 ? In all cases ? I have found that in SND_PCM_STATE_RUNNING, delay = buffer_size - avail. I have found that in SND_PCM_STATE_PREPARED, delay = 0 This causes problems. As one fills the buffer in SND_PCM_STATE_PREPARED , delay stays at 0, but when the buffer fills enough and moves to state SND_PCM_STATE_RUNNING, the delay value suddenly jumps to delay = buffer_size - avail. This causes problems with applications that need delay to be as accurate as possible at all times. Is this a bug in alsa09, or should I ignore delay and just use the buffer_size - avail value. Obviously, in SND_PCM_STATE_XRUN, delay is invalid.with avail values sometimes becoming buffer_size! so should not be used. Cheers James --- 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] Why do I get broken pipe on write to a pcm instatePREPARED?
Clemens Ladisch wrote: The behaviour of polling during capture is just fine: RUNNING: block until avail_min is available, then return POLLIN DRAINING: return POLLIN until buffer is empty, then return POLLERR (other states: POLLERR) The current behaviour for playback is: PREPARED: return POLLOUT until the buffer is full, then return POLLERR Why would the buffer get full in PREPARED state ? Surely any sensible, start_threshold should cause the state to change to RUNNING before the buffer is full. I can't see any reason to not to use start_threshold in order to get from PREPARED to RUNNING. RUNNING: block until avail_min can be written, then return POLLOUT DRAINING: block (until state changes) (other states: POLLERR) I want the behaviour in the PREPARED state to be similar to the RUNNING state, i.e. return POLLOUT until the buffer is full, then block. My reason for this is that a buffer overflow in the PREPARED state is similar to a pipe connected to an application which currently doesn't read from the pipe (- blocking), and not a pipe which isn't connected at all (- EPIPE). And as Anders pointed out at the start of this thread, there are situations where this case isn't an error. Regards, Clemens Cheers James --- 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] Why do I get broken pipe on write to a pcm instatePREPARED?
Anders Torger wrote: On Wednesday 09 October 2002 15.28, you wrote: Clemens Ladisch wrote: The behaviour of polling during capture is just fine: RUNNING: block until avail_min is available, then return POLLIN DRAINING: return POLLIN until buffer is empty, then return POLLERR (other states: POLLERR) The current behaviour for playback is: PREPARED: return POLLOUT until the buffer is full, then return POLLERR Why would the buffer get full in PREPARED state ? Surely any sensible, start_threshold should cause the state to change to RUNNING before the buffer is full. I can't see any reason to not to use start_threshold in order to get from PREPARED to RUNNING. Because another thread that should start the card is not ready yet. In threaded programming it may be fully natural to first fill the output buffer and then start the card from another thread. Of course, you can always adapt to how it works (for example if there would always be a start threshold which could not be changed), but it is best if poll() works in a way that is expected, and is conforming to standards. If poll() behaviour is changed to the proposed, we will not only get a more clear standard conformance (what is conforming or not is however always a question of interpretation, since there is no relevant standard that directly relates to sound cards), but a more flexible API in terms of how to design your multi-threaded/process applications. /Anders Torger Ok, as far as Iam concerned, my application will not care. It never reaches the PREPARED, buffer full state because I use start_threshold. Although my application is multi-treaded, all the audio out happens in a single thread. Other threads do the grabbing the data of the hard disk etc. and buffering it in memory. I do think that any poll should block unless data can be written to the file handle irrespective of the BLOCK/NON-BLOCK status of the file handle. BLOCK/NON-BLOCK should only effect open and write calls, not poll calls. I don't understand which applications prefer: - 1) PREPARED: return POLLOUT until the buffer is full, then return POLLERR. and which would prefer (as suggested): - 2) PREPARED: return POLLOUT until the buffer is full, then BLOCK. As I understand it, the poll works correctly in RUNNING state? I think (2) would basically kill all single thread apps so on balance, I think (1) is the best to go with for now. The application I have thought of is that an application might want to fill many file handles/streams buffers but keep them in PREPARED state. Then release all the channels at the same time so that they play in sync. But for that one does not need to do any polling in PREPARED state. One just does snd_pcm_write until one gets an error. I guess the solution to all this would be to provide two different poll/snd_pcm_wait calls so the application writer can choose which behaviour they want. This would then make everyone happy, and also not break any old apps. Another solution is for the application writer to use the pthreads pthread_cond_wait() to get one thread to wait until another thread has done some work. Then alsa would not have to change at all. ;-) Cheers James --- 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] problems: flushing during snd_pcm_wait()
Hello
I have an application that has many different threads.
The sound card's PCM buffer is full during playback, and one thread is
currently in snd_pcm_wait() waiting for enough space to appear in the
buffer before doing the next snd_pcm_write().
A different thread wants to flush the buffer. There are two types of
flush: -
1) Immeadiately empty the buffer.
2) Stop accepting snd_pcm_write() commands until the current buffer has
drained.
Can someone please tell me which API calls I should make to get the
buffer to flush properly.
I am currently doing things like: -
int flush() {
snip...
if ((result=snd_pcm_reset(this-audio_fd)) 0) {
printf(audio_alsa_out: Reset call failed err=%d\n,result);
}
if ((result=snd_pcm_drain(this-audio_fd)) 0) {
printf(audio_alsa_out: Drain call failed err=%d\n,result);
}
if ((result=snd_pcm_prepare(this-audio_fd)) 0) {
printf(audio_alsa_out: Prepare call failed err=%d\n,result);
}
}
But this is causing all sorts of problems, one of which is that the
application hangs, and has to be killed with -9, and the audio hardware
ring buffer is left playing a repeated sound even with: -
/proc/asound/card0/pcm0p/sub0# cat status
closed
Cheers
James
---
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] Mixer control elements.
Hello I was wondering how easy it would be to add a classification to each control element. (switches, volume, capture on/off etc.) The classification would be as follows: - 1) Used during capture. I.E. Switches and volume controls for anything one can record. 2) Used during playback. I.E. Switches and volume controls for anything one can play. 3) General control. I.E. Hardware config. E.g. The SB Live Digital/Analogue switch for Digital SPDIF out/Analogue Center and LFE audio out. Then have alsamixer be able to filter the display using these 3 categories. User presses a key, and alsamixer displays only the controls used to effect sound playback. User presses another key, and alsamixer displays only the controls used to effect sound recording. User presses another key, and alsamixer displays only the controls used to do other stuff. This sort of functionallity could help users understand what each control does better. In my view the SB Live has so many controls, it is very difficult to sort out which ones to use. Currently, alsamixer seems to link playback and record volumes, that should be separate. Cheers James --- 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] Problems with snd_pcm_hw_params_can_pause (). etc.
Jaroslav Kysela wrote: On Sat, 12 Oct 2002, James Courtier-Dutton wrote: Currently, the state of play is that snd_pcm_hw_params_can_pause () should not be called until one has first done the first snd_pcm_hw_params() I start with snd_pcm_hw_params_any(this-audio_fd, params); then go about setting params, e.g. snd_pcm_hw_params_set_access() snd_pcm_hw_params_set_format() etc. Then snd_pcm_hw_params() then snd_pcm_hw_params_can_pause (params) If the snd_pcm_hw_params_can_pause (params) goes before the snd_pcm_hw_params() an invalid result is returned. I.E. the result is always 1 even for cards which don't support it. I think the documentation should make it clear when one should use snd_pcm_hw_params_can_pause (). or maybe snd_pcm_hw_params_any() should be modified to correctly fill the can_pause bit. Maybe I have missunderstood the API, but I would prefer the approach of first retrieving the current hw params, then go about modifying it, then writting it back. If one has not set any hw params yet, it would fill But what's current configuration? What you want to prefer? rate? channels? period_size? No, application should give these hints to driver. the structure with the most general case, then allow the application to set params to further restrict the config. I had assumed that snd_pcm_hw_params_any() did the retrieving of the current hw params, but reset to the least restrictive settings. I don't think can_pause is anything an application can set, the hardware on the card decides that, so the snd_pcm_hw_params_any() should cause can_pause to return a valid setting that matches the hardware, instead of having to wait for the params to be written to the card with snd_pcm_hw_params() before can_pause is set accurately. All these functions needs exactly one configuration at input. The snd_pcm_hw_params() function chooses one configuration and sets it to hardware. I've updated documentation. Jaroslav Thanks for the documentation update. I currently use the inline docs contained in alsa-lib/pcm/pcm.c. Is that the ones you update ? I only mentioned it because I made the mistake of putting the can_pause() before the snd_pcm_hw_params() without knowing that it would not work correctly, so I just wanted the documentation to be updated so that no one else would make the same mistake. I think the point I was trying to make is that one should be able to call snd_pcm_hw_can_pause() at any time. One should not have to wait until one has snd_pcm_hw_params() has been called. At this point I am assuming that the result of snd_pcm_hw_can_pause() is always constant, and does not depend of any hw_params that have been set. But now I come to think of it, this might not be true. I think the SB Live can do pause/resume in normal mode, but cannot do it in AC3 passthru mode using the DSP TRAM. But as a general point, this does not really matter too much to me now, because I will be using snd_pcm_hw_params_current() that you have kindly added to the API. ;-) I will have to wait until the next release of alsa09 before I actually code the change, because I cannot expect all my users to install alsa09 from CVS. :-( As a sub note, maybe snd_pcm_can_pause() should return some sort of error code, or throw an assert if the application programmer has put it before snd_pcm_hw_params() instead of returning a perfectly useable result that is baseless. I think an assert() would be acceptable, as this is a application programming error and not a user initiated error. It would then force the application programmer to get it right first time. ;-) Cheers James --- 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] alsa memory leaks
Has anyone run a diagnosis tool like memprof on an application that uses alsa for audio out ? I recently did this, and have found that alsa is a little leaky. It is mainly the mixer part of alsa. Here is an example backtrace for the call to the malloc that is never freed even if the application exits. Maybe I am just missing the alsa-lib api call to free up all the memory, but I thought I would mention it anyway. There are lots of these: - Leaked 0x8106038 (12 bytes) [0x400157b0] bag_add(): /alsa-lib/src/mixer/bag.c:47 snd_mixer_elem_attach(): /alsa-lib/src/mixer/mixer.c:88 simple_add1(): /alsa-lib/src/mixer/simple.c:966 simple_event_add(): /alsa-lib/src/mixer/simple.c:1029 simple_event(): /alsa-lib/src/mixer/simple.c:1062 hctl_event_handler(): /alsa-lib/src/mixer/mixer.c:175 snd_hctl_throw_event(): /alsa-lib/src/control/hcontrol.c:178 snd_hctl_load(): /alsa-lib/src/control/hcontrol.c:567 snd_mixer_load(): /alsa-lib/src/mixer/mixer.c:448 ao_alsa_mixer_init(): /xine-lib/src/audio_out/audio_alsa_out.c:858 Cheers James --- 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] problems: flushing during snd_pcm_wait()
Thankyou, I will use snd_pcm_drop(), but as a side note, what actually does snd_pcm_reset() do. Just resetting delay to 0 does not make much sense to me. It drops all samples in the ring buffer (thus reseting delay to 0). Note that everybody are welcome to improve the current documentation (preferably with patches). Jaroslav Ok, so snd_pcm_drop drops all samples in the buffer, so I would assume this sets the delay to 0. so snd_pcm_reset drops all sample in the buffer, so as you say is sets delay to 0. So my question is What is the difference between the 2 functions? Cheers James --- 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] Problems with snd_pcm_hw_params_can_pause (). etc.
Currently, the state of play is that snd_pcm_hw_params_can_pause () should not be called until one has first done the first snd_pcm_hw_params() I start with snd_pcm_hw_params_any(this-audio_fd, params); then go about setting params, e.g. snd_pcm_hw_params_set_access() snd_pcm_hw_params_set_format() etc. Then snd_pcm_hw_params() then snd_pcm_hw_params_can_pause (params) If the snd_pcm_hw_params_can_pause (params) goes before the snd_pcm_hw_params() an invalid result is returned. I.E. the result is always 1 even for cards which don't support it. I think the documentation should make it clear when one should use snd_pcm_hw_params_can_pause (). or maybe snd_pcm_hw_params_any() should be modified to correctly fill the can_pause bit. Maybe I have missunderstood the API, but I would prefer the approach of first retrieving the current hw params, then go about modifying it, then writting it back. If one has not set any hw params yet, it would fill the structure with the most general case, then allow the application to set params to further restrict the config. I had assumed that snd_pcm_hw_params_any() did the retrieving of the current hw params, but reset to the least restrictive settings. I don't think can_pause is anything an application can set, the hardware on the card decides that, so the snd_pcm_hw_params_any() should cause can_pause to return a valid setting that matches the hardware, instead of having to wait for the params to be written to the card with snd_pcm_hw_params() before can_pause is set accurately. Cheers James --- 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] Oops? Linux 2.4.19 + snd-usb-audio (ALSA 0.9.0-rc5)
Scott Parkerson wrote: Has anyone else seen a kernel panic when unplugging a busy (i.e. actively playing music) USB audio device using snd-usb-audio with Linux 2.4.19 and ALSA 0.90-rc5? I'll send my ksymoops output in a bit... Just wondering if this is just seen on my box. Thanks, Scott Parkerson - Software Developer Ateb, Inc. 919.872.1275 www.ateb.com I think that will happen with most PCMCIA and USB devices in linux. For my system, I have to specifically rmmod all the modules associated with the device before removing it. I have written scripts to help me. E.g eject-nic that is for ejecting the Network interface PCMCIA card. Also, eject-camera etc. I think people will have to wait until kernel 2.5.x or above for better plug-n-unplug support. Maybe I am wrong, and it is just a co-incidence that all the devices I have had bugs in the drivers. Cheers James --- 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: Phase Reversal on Santa Cruz (cs46xx)
Just as a general point to note. We are not putting the audio card into AC3 mode. We might be doing passthru mode or spdif non-audio, but never just AC3 mode. I help with the xine (a free media player http://xine.sf.net) that can play DVDs. DVDs have AC3 audio tracks and DTS audio tracks. xine uses spdif non-audio and passthru mode when used with alsa. It can therefore output AC3 and DTS tracks to an external decoder. Summary: - AC3 is the wrong term to use. spdif passthru is probably a better term to use, as the current ac3_mode seems to imply that DTS audio might not work. Cheers James --- 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] Using alsa-lib for timing
Robert Spier wrote: Paul, Thank you for your clear explanation. I've submitted a small documentation patch to the sf.net project which might prevent the next person who comes along from falling into the same trap. the basic problem is that you are going about this in the wrong way. there have been many discussions here and on LAD about how to do this sort of thing. its not easy. your first and most basic problem is that you are trying to sync two clocks (the video frame clock and the audio frame clock) that do *not* run in sync. any solution that starts with this as its approach is going to fail, for better or for worse. We've gone back to our standby method of timing everything off the audio, using polling to trigger the RTC for a per-frame delay. It's CPU intensive, but works well enough for our purposes. (Although definitely sub-optimal and quite nasty.) -R One approach I have taken to try and overcome the problem of using audio card clocks and system clocks, it that I use resampling. So I use the system clock to sync audio/video, and then let the audio card ask for samples, using a sort of callback method from alsa, similar to the way jack gets alsa to simulate a callback interface. If my application notices that the sound card is outputting samples too quickly(I.E. audio hardware clock is slightly faster than the system clock), it does some resampling, thus making the sound card have to output more samples. As the sound card now has more samples, it then is kept in step with the system clock. I have found that the linux system clock is always more accurate than most sound card clocks, so I believe that this approach is quite good. Cheers James --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: Avoiding xruns... was Re: [Alsa-devel] smix plugin available?
Paul Davis wrote: I am currently taking the following approach: - Always prepare 2 audio hardware periods of sample frames in advance inside the user app. 1) snd_pcm_wait() 2) write() 3) prepare new sample frames, then go back to (1). for lower latency, you'd do: 1) snd_pcm_wait() 2) prepare new sample frames 3) write(), then go back to (1). but for the kinds of things you are describing, your original order seems OK. --p I suppose it depends on what latency we are measuring. My first concern is avoiding xruns, and preparing new sample frames takes quite a lot of time. For my application, it does not really matter how long it takes for the samples to reach the speakers, it is just that we have to know very accurately how long it is in fact taking. (so we use the delay() function.) The other issue is the avoiding of xruns, so I think my suggestion is better than yours for xrun avoidance. Cheers James --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] smix plugin available?
tomasz motylewski wrote: Please stop the complication of available/delay etc. Just the raw pointer. Each application knows where its application pointer is, so it can easily calculate delay/available and decide for itself whether there was an overrun or not. I use the delay() function. I help write a multi media application that needs to sync audio to video. So the question I ask alsa-lib is If I write() now, how long will it be before those samples come out of the speakers? So, I very much need delay(), but I also use available so that I can program alsa when to exit the snd_pcm_wait() poll. I.E. Only exit the snd_pcm_wait when there are enough free space in the buffer for me to bother with a new write() call. Cheers James --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Avoiding xruns... was Re: [Alsa-devel] smix plugin available?
I have read your comments below, and I would like to try to explain the problems I am coming up against when writing a multi-media app. I am not going to say that I know everything about kernel scheduling, but for multi media applications, avoiding xruns is a major concern. This becomes particularly important in SPDIF passthru modes, because if one is outputting AC3 or DTS non-audio packs to an external decoder, an xrun will corrupt an entire AC3 or DTS pack that is equivalent to anything between 512 - 4096 PCM Sample Frames. So, loosing a single sample will be very noticable to the user. I am currently taking the following approach: - Always prepare 2 audio hardware periods of sample frames in advance inside the user app. 1) snd_pcm_wait() 2) write() 3) prepare new sample frames, then go back to (1). Is this approach the best approach to use in order to avoid xruns ? Using the plug interface does make the user app easier to write, but is using the plug interface adding too much overhead so as to increase the risk of xruns too much ? Cheers James Jaroslav Kysela wrote: On Wed, 27 Nov 2002, James Courtier-Dutton wrote: Paul Davis wrote: the APIs that are used to write almost all audio software code in production these days all use a callback model. Sorry for questioning this statement. Of course we all don't have any statisti cal data but you miss what I see as the majority of applications that use audio devices: 1) games 2) media players 3) GUI sounds (i.e. accessibility) this is a fair point. i apologize. i have my head so far inside the audio software for musicians box that i tend to fail to see such applications :) however, the very fact that the applications developers of such programs really don't know much (if anything) about audio programming, and probably don't want to know much about it either, suggests that an API like ALSA which exposes the full HAL is probably a mistake. again, i consider PortAudio a vastly preferable solution. I would like to point out that a callback api would work just as well as an open/write/close api for 1) games 2) media players 3) GUI sounds (i.e. accessibility) I have to agree with Paul on the fact that a callback approach is really the ONLY real option. Here is my reasoning: - 1) My perspective is from (2) Media players and not Pro-Audio 2) Sound Hardware tends to have very small buffers. 3) For nice sounding audio, these buffers should never run dry. I.E. No XRUNs. 4) A open/write/close api will never ever be able to guarantee no XRUNs, as it has no control on when it will get scheduling time to do the next write. 5) With a callback approach, the kernel would be notified by the sound hardware that it was ready for new samples, the kernel could then adjust the scheduler, so that the callback function was called ASAP. The callback function then only has to decide which samples to give. If the callback function could receive a delay value from the sound hardware at each callback, a media player would then have all the information it needed to do full audio/video sync. Sorry, it's not as easy as you've described. It's not possible to invoke any user code from the kernel code directly. There is a scheduler which is informed that a task has been woken up. It depends on scheduler when the task is really invoked. It's quite same as for the r/w model where the application is notified over poll that something occured. 6) I don't need sample sync, but I do NEED callback based api to provide me with no XRUNs. I don't think that there is some difference. If the scheduler don't give you enough time, the audio stream is somehow broken on all architectures. Summary: - The only way to cure XRUN problems is with a callback based api. All application that currently use open/write/close apis, can just as easily use a callback api. Let's go and see the implementation: The callback model is good for perfect sync between applications. It can do (and does) chaining of more sources, arbitrating (removing invalid sources) and so on. It is simply something over the audio HAL. If it really helps, it's a different point. The discussed difference (a few months ago) was in a count of the task context switches. With jack, you have these context switches (daemon and two applications mixed together) for one period of samples (* means a context switch): jackd -* app1 -* app2 -* jackd - soundcard With r/w model and a sample mixing server implemented in the user space, you can get this for one period of samples: mserver - soundcard -*(ring buffer does not contain enough samples) app1 -*(ring buffer does not contain enough samples) app2 In real real-time setup, there will be two periods (thus app1 and app2) will be woken up all times. So, in real world the context switches are for one period of samples: mserver -* app1 -* app2 or mserver -* app2 -* app1 Note
Re: [Alsa-devel] Am I asking the right people ?
Bruce Paterson wrote: Am I sending these queries about the operation of alsa through the API to the right place ? I'm trying to use alsa for a real scientific application and I'm starting to worry it simply isn't ready yet. I don't pretend to be a developer of alsa drivers themselves, and I'd hoped I didn't need to become one. I understand alsa needs many people debugging it and finding problems to make it bulletproof (afterall there would be a myriad of different possible configurations people can use). However, the silence I get in reply to queries is golden (unlike the distortion I'm getting from the soundcard) ! It's possible I'm not using the alsa API in the way intended and bringing the problems upon myself, but please, somebody tell me ! It would be a real blow to the progress of linux in this company if all the alsa work had to be scrapped. Apologies for the frustrated tone. Bruce Paterson wrote: Behaviour: The output sound is perfect for about 2 minutes. After that every now and then I get distortion in the audio. No xruns or errors are reported in the software. It sounds like only part of the output buffer is correct (the general gist is right, but there's crap and warbles there as well). You could try using a different linux application, and thus narrow down the problem to your app or alsa. I helped with the xine (xine.sf.net) media player, and it has native alsa support, and detects xruns well. You might want to try that. Alsa also emulates oss, so any application that uses oss can also be used to do the test. It might be that your software is not detecting xruns correctly. The problems that you are getting, sound to me that you are getting XRUNs. It might be worth trying your application with a different sound card. If that fixes the problem, it might point to a bug in the alsa driver for your particular sound card. Cheers James --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] smix plugin available?
Paul Davis wrote: the APIs that are used to write almost all audio software code in production these days all use a callback model. Sorry for questioning this statement. Of course we all don't have any statisti cal data but you miss what I see as the majority of applications that use audio devices: 1) games 2) media players 3) GUI sounds (i.e. accessibility) this is a fair point. i apologize. i have my head so far inside the audio software for musicians box that i tend to fail to see such applications :) however, the very fact that the applications developers of such programs really don't know much (if anything) about audio programming, and probably don't want to know much about it either, suggests that an API like ALSA which exposes the full HAL is probably a mistake. again, i consider PortAudio a vastly preferable solution. I would like to point out that a callback api would work just as well as an open/write/close api for 1) games 2) media players 3) GUI sounds (i.e. accessibility) I have to agree with Paul on the fact that a callback approach is really the ONLY real option. Here is my reasoning: - 1) My perspective is from (2) Media players and not Pro-Audio 2) Sound Hardware tends to have very small buffers. 3) For nice sounding audio, these buffers should never run dry. I.E. No XRUNs. 4) A open/write/close api will never ever be able to guarantee no XRUNs, as it has no control on when it will get scheduling time to do the next write. 5) With a callback approach, the kernel would be notified by the sound hardware that it was ready for new samples, the kernel could then adjust the scheduler, so that the callback function was called ASAP. The callback function then only has to decide which samples to give. If the callback function could receive a delay value from the sound hardware at each callback, a media player would then have all the information it needed to do full audio/video sync. 6) I don't need sample sync, but I do NEED callback based api to provide me with no XRUNs. Summary: - The only way to cure XRUN problems is with a callback based api. All application that currently use open/write/close apis, can just as easily use a callback api. Cheers James --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Major Bug in Alsa 0.9 for over 1 year
[EMAIL PROTECTED] wrote: Hello, I allways have the same bug when trying to modprobe the cs4232 or cs4236 sounddriver for my Terratec EWS654XL soundcard. The bug is called unresolved symbol, this bug exists in ALSA 0.9 since the existing of ALSA 0.9. I tried nearly every ALSA 0.9x version. This bug is mostly causes by in-correct install of alsa. In order to install alsa, you must first compile and install your own kernel. Once the kernel is installed and running, you can then compile and install alsa-driver. Once you have alsa-driver installed, with all the modules, you can then compile and install alsa-lib. Also, the kernel must be compiled with the same compiler as the alsa-driver modules. E.g. You cannot have compiled the kernel with gcc 2.95 and compile alsa-driver with gcc 3.2. Using different compilers causes all sorts of strange un-predictable problems. I took a few days once tried to track down a kernel oops, only to find that simply compiling both kernel and kernel-module with the same compiler fixed the issue. That should solve all unresolved symbols. Cheers James --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] SIS7012 SPDIF support
Takashi Iwai wrote: thanks. looking at the codes, it seems that no special handling for the chip. it simply sets up the ac97 registers. the patch below is a quick hack to set the spdif rate on the first playback pcm device. in addition, you'll need to set up the following mixer controls: - 'IEC958 AC97-SPSA' to 0 (slots 3/4). - 'IEC958 Playback Switch' to on. you might need to set up 'IEC958 Playback Default', too, but it might not... try once the above two switches at first. Takashi I have done some further investigation, and have discovered the type of ac97 chip used. I attach output from the ac97#0regs /proc/asound/card0 file. Here is the url to download datasheets of the chip. It is an ALC650 Chip. http://www.realtek.com.tw/downloads/downloads1-3.aspx?lineid=5famid=Allseries=8refdesign=True From my analysis, I think that we should be setting bit 2 of register 0x2a to get SPDIF out. Is it possible to set this via alsamixer, or do I now have to open the device with a particular name, e.g. iec958:AES0=0x6,AES1=0x82,AES2=0x0,AES3=0x2 The chip can set non-audio bits etc, so we should really be able to support opening with the iec958:...etc. name. If you think I am on the right lines here, then what functions do we have to add to get it to parse iec958 lines correctly. Cheers James 0:00 = 5980 0:02 = 9f1f 0:04 = 0:06 = 801f 0:08 = 0:0a = 801e 0:0c = 801f 0:0e = 801f 0:10 = 9f1f 0:12 = 9f1f 0:14 = 9f1f 0:16 = 9f1f 0:18 = 9f1f 0:1a = 0:1c = 0:1e = 0:20 = 0:22 = 0:24 = 0:26 = 000f 0:28 = 05c7 0:2a = 05c1 0:2c = bb80 0:2e = bb80 0:30 = bb80 0:32 = bb80 0:34 = 0:36 = 9f80 0:38 = 9f9f 0:3a = 2000 0:3c = 0:3e = 0:40 = 0:42 = 0:44 = 0:46 = 0:48 = 0:4a = 0:4c = 0:4e = 0:50 = 0:52 = 0:54 = 0:56 = 0:58 = 0:5a = 0:5c = 0:5e = 0:60 = 0:62 = 0:64 = 0808 0:66 = 0808 0:68 = 0:6a = 0:6c = 0:6e = 0014 0:70 = 0211 0:72 = 00a0 0:74 = 0043 0:76 = 0001 0:78 = 0102 0:7a = 57c6 0:7c = 414c 0:7e = 4720
Re: [Alsa-devel] SIS7012 SPDIF support
Takashi Iwai wrote: oops, it seems like my mistake in the last change. could you try the attached patch? Takashi That seems to have helped. We now get sliders. We now get ac3 and dts sound with device name iec958:AES0=0x6,AES1=0x82,AES2=0x0,AES3=0x2 and pcm with device name iec958:AES0=0x4,AES1=0x82,AES2=0x0,AES3=0x2 We currently get no sound with device name: - default front We only have the spdif connected. So if sound is comming out of the analogue port, we will not know about it. It would be nice to get sound output with default and front, because then oss emulation and alsa's automatic resampling would also work. The problem with the device is that if you want a 48000hz spdif out, all inputs have to also be 48000hz. So, if we open the device for 44100 hz output, it would be nice if the spdif automatically changed to 44100 hz as well. Currently, sound only seems to work if you send it to the device at 48000 hz. E.g. DVDs audio tracks. Cheers James --- 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] Single process freeze when opening capture device
Jaroslav Kysela wrote: It is limit of current alsa-lib configuration. We cannot distinct playback and capture. But I am not sure, if returning an error helps you (surround40 configuration is NOT valid for emu10k1). I suggest to fix jack to allow different names for playback and capture with different count of channels. Jaroslav Surround40 playback seems to work on my SB Live emu10k1. Some SB Live cards have 2 stereo audio inputs, so in theory they should be able to do Surround40 capture as well. Can the SB Live do 4 channel full duplex, or is there another factor involved. Cheers James --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! 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] PC Hanging.
Hello, I have a problem. At some point my PC just halts, no panic message, nothing, except that the following: - Number lock - off Caps lock - flashing Scroll lock - flashing. The only way out if the power cycle the pc. Can anyone tell me where to start looking to track this down ? I can't find any documents explaining this situation. Cheers James --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! 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] position at sun/paul davis
Orm Finnendahl wrote: Am Freitag, den 30. Mai 2003 um 07:00:02 Uhr (-0700) schrieb Mark Knecht: Orm, I must say that I think this is the biggest bunch of crap I've seen on a Linux list in a long time. This list is no place for this sort of discussion and it's really a low act on your part to publish innuendo and rumor like it was the truth. Hi Mark, my sincere apologies, if I offended you, Paul or anybody else on this list. Paul posted this information on jackit-devel, as was the job offer so I considered my post appropriate. No low act intended on my side. I'll quote his mail below in case you didn't read it. sorry fore the noise. I'll take the blame. Orm --- ---Original Message--- From: Paul Davis [EMAIL PROTECTED] Sent: 05/28/03 03:55 PM To: [EMAIL PROTECTED] Subject: [Jackit-devel] Re: position at sun I'd just like to point out that Sun decided that my resume wasn't adequate for the position that was posted here yesterday. Apparently, Sun's representative said the candidate must have in depth Linux kernel experience. Also experience in implementation of OSS and/or ALSA framework and has contributed to the Linux Opensrc community. I'm taking this as a personal affront for the time being. If you think you or someone else has a better resume to match what Sun advertised, you should probably get in touch with them. Be sure to send Sun my regards. Oh well, Ardour is a more interesting project anyway :) --p --- I think that this whole job opening was a prank. If they don't accept people like Paul, they obviously have no idea what linux audio is all about. I think that if this job opening was for real, the offer would have come from a [EMAIL PROTECTED] email address. Sun should not have to call on a 3rd party just to send emails to a mailing list. If this opening was in fact truly from sun, then too bad, because I doubt they will find anyone now that they have rejected Paul. Summary: I think the job opening at sun email was for some other devious purpose apart from offering a job. Cheers James --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! 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] dmix and oss.
Is it possible to get the OSS emulation to use the dmix alsa plugin ? Basically, so one can get multi-open /dev/dsp on a single-open sound hardware. Cheers James --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! 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] SIS7012 SPDIF support
Is the SPDIF output of the SIS7012 (i810 with ac97) supported in alsa. If so, how does one enable the SPDIF out. The current kernel OSS module supports it. Cheers James --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! 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] please ignore this - Re: Is the alsa-conf directory on the cvssupposed to compile ?
James Courtier-Dutton wrote: See subject. It does not compile here. Cheers James --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! 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] Is the alsa-conf directory on the cvs supposed to compile ?
See subject. It does not compile here. Cheers James --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! 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] SIS7012 SPDIF support
Takashi Iwai wrote: At Mon, 02 Jun 2003 17:01:42 +0100, James Courtier-Dutton wrote: Is the SPDIF output of the SIS7012 (i810 with ac97) supported in alsa. If so, how does one enable the SPDIF out. The current kernel OSS module supports it. which OSS (kernel) version supports spdif out on this chip? i'd like to take a look. ciao, Takashi The user I was talking to on irc had kernel 2.4.21-ac-rc1 or something like that. I have root access to his box if you need any more info. linux-2.4.21-rc1.tar.bz2 I attach the source files that I think you need. Cheers James sis7012.tar.bz2 Description: Binary data
[Alsa-devel] Alsa driver for bluetooth headset.
Hi, I am about to start writing an alsa driver for a bluetooth headset. Is anyone else working on this, or shall I start from scratch. I will be using information from the kernel bluetooth modules together with the affix project. (affix.sf.net) Once finished I will post the source code to this list using the same license as alsa uses. Cheers James --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] problem with MU -LAW
mahendra sp wrote: hi, alsa people, I have wriiten the application which realises full duplex.But there is playback buffer underrun proble. The buffer tries to read the value but -ve value. After writink the -ve value for some timesay 3 minutes, it becomes alright. again after some time buffer under run occurs. whts the problem . how to over come it. is it dependednt on periodsize and buffersize? and also i want to implement G711. does it happen automatically by using snd_pcm_format_mulaw? if not how to do it? thanks, regards, mahendra ___ G.711 uses two audio formats. A-Law (Europe), and mu-Law(USA). So, if one talks about A-Law and mu-Law, one is talking about G.711 Cheers James --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] usb audio callback questions.
I have a question regarding the callbacks in the usbaudio.c driver.
The callback is defined as: -
/*
* complete callback from data urb
*/
static void snd_complete_urb(struct urb *urb, struct pt_regs *regs)
The callback is set up with: -
u-urb-complete = snd_usb_complete_callback(snd_complete_urb);
The issue I have is that urb-complete is of type: -
struct urb;
typedef void (*usb_complete_t)(struct urb *);
struct urb
{
snip
usb_complete_t complete;// pointer to completion routine
snip
};
So, why is the struct pt_regs *regs there ?
I would think that
static void snd_complete_urb(struct urb *urb, struct pt_regs *regs)
should change to
static void snd_complete_urb(struct urb *urb)
Cheers
James
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] TRAM on Audigy
p z wrote: Hi, I wanted to add support for TRAM on Audigy to emu10k1 driver. I look (tryed) at OSS driver and found that TRAM is not working too. :-( Then I use trial and error method and found how to setup TRAM on Audigy. I know how to read from and write to TRAM in EMU10k2 DSP program but not more. Is there any documentation on using TRAM on Audigy, or am I only one (except Creative and Creative NDA signer) who know how to use TRAM on Audigy ??? I need more info on how is TRAM working on SB Live: TANKMEMADDRREG_CLEAR - Clear tank memory TANKMEMADDRREG_ALIGN - Align read or write relative to tank access TANKMEMADDRREG_WRITE - Write to tank memory TANKMEMADDRREG_READ - Read from tank memory Please help Peter Zubaj PS: If no one knows more, I will make patch against current CVS and send it to this list. (mayby AC3 passthrough using TRAM will work too :-)) I heard that one will not have to do TRAM AC3, one can just select a different interpolator (A special NULL interpolor). I have not tested my self, but I saw emails about it about 1 year ago. I think that it is just old SB Live cards that need the TRAM method. Cheers James --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ring buffer pointer accuracy.
Takashi Iwai wrote: At Fri, 11 Jul 2003 17:28:08 +0200, Giuliano Pochini wrote: On Thu, 10 Jul 2003 16:31:28 +0100 James Courtier-Dutton [EMAIL PROTECTED] wrote: Hi, When an application reads the avail or delay pcm values: - 1) how accurate are they? 2) does the accuracy depend on the sound card driver being used. Worst case accuracy is about one period AFAIK. It depends on the sound chip because the low level driver reads the DMA pointer (or something) from some hardware register or it can know the DMA pointer when it receives an interrupt at the end of a period. yes. if the accuracy is in period size, at least it should work somehow. e.g. the time-slider of a player might not move so smooth but it must not be critical. Takashi I would like some idea of how accurate the snd_pcm_delay() result is likely to be. If I am trying to syncronise video to audio, and I notice a difference between audio and video, I need to know how accurate I can make it. If some cards only update delay once per period, but others update it all the time, I would like the application to know about it, so it can decide how accurately it can actually get audio and video in sync. I.e. On some cards it would only correct for sync if it is off by 1 period or more, but with other audio cards it could be sample accurate. I have a sb live audio card and it seems to update with sample accuracy. Cheers James --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] USB disconnect/connect messages
Takashi Iwai wrote: At Mon, 21 Jul 2003 00:40:32 +0100, James Courtier-Dutton wrote: Hi, Is there any way to tell if a USB sound card has been disconnected or not? IIRC, this is not notified to the application. the app simply would get an error at the further access. it sounds not bad to notify the status change to the application by some way. perhaps we can add a new control element for this purpose. and after disconnection, only this element survives to communicate with the application... So, the app gets an error. Which error? How do I test to see if the error is due to a non-existant device, or just underrun/overrun etc. I would be happy if there was a reliable way to tell. This would only give us the disconnect event. How would one know if the device was connected again? Maybe a tidy way to do this would be a new alsa events device. So, we open the events device, and it can then inform us of hardware changes. I know that USB is the only form of device that connects/disconnects via a user action at the moment, but I am sure others will come along. E.g. Bluetooth etc. For USB, usbaudio.c definitely gets informed about usb device removal/addition, how can we get that message passed up to the application? Cheers James --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] SPDIF and alsa, does it works for all cards/receivers?
Gregoire Favre wrote: Hello list ;-) I have a stupid 5.1 system from Hercules which don't work perfectly in the sense, that when I connect it to a SBlive with a coaxial connexion it works (I can hear lots of noise, but my cable is very bad), my receiver goes in Dolby Digital mode with Dolby Digital signal and go back to Stereo mode without Dolby Digital signal: fine with SBlive. Unfortunately, my motherboard has an integrated intel8x0 with optical SPDIF, and I can't by any way play any Dolby Digital signal with it, I can only hardly plays with the http://bitstreamout.sourceforge.net/ which forward the signal from DVB and sent it to the soundcard SPDIF, then my receiver turns in Dolby Digital on Dolby Digital signal, and stay in this mode even after the end of the Dolby Digital signal... and then refuse to play anything at all??? And even worse: I have a Digital 7.1 card, with it I cannot put my receiver in 5.1 at all??? I just copy an expert, Dr. Werner Fink, as he spoke in the [EMAIL PROTECTED] mailing list about a problem with AC3overDVB: As long as the hardware on the DVB cards are not able to put the 16bit none audio PCM data stream into a 32bit none audio S/P-DIF transport stream all receivers which uses the bit flags of the S/P-DIF transport stream for identifying none audio loose. All S/P-DIF data get from the DVB card to not have the none audio bit set. AFAIK this is a hardware bug (or better this is the information I've got from TT) ... Is there such limitation with either my integrated intel8x0 or with the cs46xx card or??? Or is it only ALSA limitation (for example, with the Digifire 7.1 it works under windows...)? Grégoire __ http://www-ima.unil.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED] You are correct, SPDIF and alsa does NOT work with all cards and all receivers. Points to note: - 1) Does the receiver require non-audio bit to be set? Some do, some don't. My receiver does need it. 2) Does the sound card set the non-audio bit correctly when outputting AC3 data. The SB Live does this correctly. 3) Does the sound card output data un-modified from the PC to the SPDIF socket. The SB Live does interpolation on the PCM samples from the PC, so that the samples comming out of the SPDIF are different from the PCM samples from the PC. This therefore corrupts the AC3 frame (crc checks are done on it by the receiver) and no sound is output. (Normal stereo sound works because the ear cannot tell the difference between interpolated samples and the original samples). The alsa programmers have done a special work around for the SB Live problem, using something called the TRAM, in order to bypass the interpolators and get perfect AC3 output. 4) Sample rates. Some audio cards can only work at 48Khz, or only at 44.1Khz, so outputting an AC3 signal from a DVD requires 48Khz, but outputting a AC3 signal from a CD requires 44.1khz. So, depending on where the media file with AC3 in it came from, it may or may not play. It seems that SPDIF AC3 output is about the last feature that the alsa developers add when a new card is supported with alsa. As intel8x0 is used on so many different motherboards, alsa cannot hope to support them all. The important issue with intel8x0 is the type of ac97 chip used. If you run alsamixer, in the top left corner, it will have Chip: . Which chip does you motherboard have. All motherboards use different chips, and it is the programming of that chip that is required in order to set the non-audio bits. Summary: - Your problems are most likely to be (2) and (4). Cheers James --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ICH4 audio driver, SPDIF issues. I need your help!
pony wang wrote: What I want to do? I want to play a wave file (22050Hz, 2-ch) via SPDIF channel. Whats my problem? I think the ICH4 audio controller cant convert PCM data of 22050Hz to 48KHz. And the Codec cant either (codec generally accept 3 sample rates: 32K, 44.1K, 48K). Whats my question? * Is there any way to convert PCM data on audio controller side to 48K before being put to AC-Link? * The VIA 8235 audio Controller seems have the capability to convert PCM data to 48KHz before sending to AC-Link, but ICH4 seems hasnt, isnt it? * How can I play PCM data like 22050Hz via SPDIF Channel? Shall I convert it to 48KHz before I send it to audio controller? What I have tried? *My hardware: ICH4 (Audio Controller) + ALC650 (Codec) + Jazz Audio Decoder. *I tried to carry 22050Hz PCM data on slot 34 with PO Channel, with the VRA bit (Codec register 2A[0]) on. And I told Codec to get SPDIF data on slot34 too (Codec register 2A[5:4], SPSA). I try to play PCM data via PO and SPDIF simultaneously. But only the PO channel works, the SPDIF only accept 48KHz, 44.1KHz and 32KHz data. So I can't hear anything in SPDIF channel for 22050 PCM data. Thank you for your help! I'm expecting to your reply! Sincerely, Pony Resample the 22050Hz PCM to 48000Hz before sending it to the sound device. For example: The audio application xine (xine.sf.net) can do this. Just set the force rate config item to 48. Alsa's resamplers might be also be able to do this translation, if the low level hardware driver is telling the upper layers the correct information. Cheers James --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [PATCH] Fixes ac3 passthru non-audio bit settingfor AC97 codecs.
Gregoire Favre wrote: On Thu, Aug 14, 2003 at 06:05:48PM +0200, Takashi Iwai wrote: The problem I was having was that the spdif non-audio bit was not being set. This patch fixes that problem. thanks, now applied to cvs. Is there any hope to do the same for the cs46xx? Thank you very much, Grégoire __ http://www-ima.unil.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED] I don't know if I can help or not, because I don't have that sound card. If you can send me the output of :- lspci -v lspci -vn alsamixer - What is the name of the Card: and Chip: ? I will see what I can do. Cheers James --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Channel modes feature request.
I have a SB live audio card. I can open it with device names like: - surround40 (Front Left, Front Right, Rear Left, Rear Right) surround51 (Front Left, Front Right, Rear Left, Rear Right, Center, LFE) There is a requirement for: - surround41 (Front Left, Front Right, Rear Left, Rear Right, LFE) surround50 (Front Left, Front Right, Rear Left, Rear Right, Center) How can I get alsa to support these ? Cheers James --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Channel modes feature request.
Takashi Iwai wrote:
At Tue, 12 Aug 2003 00:19:34 +0100,
James Courtier-Dutton wrote:
I have a SB live audio card.
I can open it with device names like: -
surround40 (Front Left, Front Right, Rear Left, Rear Right)
surround51 (Front Left, Front Right, Rear Left, Rear Right, Center, LFE)
There is a requirement for: -
surround41 (Front Left, Front Right, Rear Left, Rear Right, LFE)
surround50 (Front Left, Front Right, Rear Left, Rear Right, Center)
How can I get alsa to support these ?
i still don't understand your question quite correctly.
do you mean open a multi-channel (5ch) pcm stream wihh the
configuration above?
if so, it's not too difficult for sb live (but not always easy for
other cards). it would look like:
Can you expand on why. Because it seems sensible to me that all cards
that do surround51, can also do surround50 and surround41.
If by what you say, it is not possible (when I say not possible, I mean
not possible with adding extra memcpy's to move the channels around in
alsa-lib) , then I will adjust my application to use the surround51 pcm,
and just mute the un-needed channel.
pcm.my5ch {
type multi
slaves.a.pcm front
slaves.a.channels 2
slaves.b.pcm rear
slaves.b.channels 2
slaves.c.pcm lfe
slaves.c.channels 1
bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave b
bindings.2.channel 0
bindings.3.slave b
bindings.3.channel 1
bindings.4.slave c
bindings.4.channel 0
}
Takashi
Cheers
James
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Detection of ALC650 rev.E
Takashi Iwai wrote: At Wed, 21 May 2003 08:04:44 +0200, p z wrote: Hi, I tested code and it doesn't work :-(. When I deleted code to detect ALC650 rev.E, it worked perfect. :-) May be: 1) MSI uses ALC650 rev.E and stil uses gpio0 to switch mic power on/off 2) detection code for ALC650 rev.E is wrong most likely the latter... perhaps chaging GPIO0 won't affect the behavior of rev.E. i'll remove it. thanks, Takashi How is the ALC650 rev.E detected? I could not see anything in the alc650 pdf specifications to indicate how to detect the ALC650 rev.E or not. Cheers James --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] intel8x0 with ICH5 and ALC650 multichannel problems.
I have a Motherboard with the ICH5 and ALC650 so I use the intel8x0 alsa
kernel driver. (Currently the version from 2.6.0-test4.)
I have managed to get SPDIF passthru working. (I posted the patch some
time ago, and it is now in 2.6.0-test4)
I cannot get multichannel working.
The motherboard has 5 audio jacks. mic, line-in, front, rear, center-lfe.
If I output just 2 channels, the sound comes out perfectly from the
front jack.
If I output in 4 or 6 channels, the sound fails on all channels.
Sometime I hear a short burst of sound on the front channel, but hardly
ever.
I am pretty sure that this is a buffer/period size problem.
My application has code is (see below)
Which function in intel8x0.c interacts with the buffer and period sizes?
The snd_pcm_hw_params_set_buffer_time_near gets full buffer_time for
stereo, but for 6 channels it does not, and has to reduce the buffer
size to some limits determined by the hardware. I think it is this
limiting/contraint code that is not working correctly.
Can anyone provide me with pointers so that I could fix this bug ?
Cheers
James
/* set the ring-buffer time [us] (large enough for x us|y samples ...) */
dir=0;
err = snd_pcm_hw_params_set_buffer_time_near(this-audio_fd, params,
buffer_time, dir); /* buffer_time before call = 100 */
if (err 0) {
printf (audio_alsa_out: buffer time not available\n);
goto __close;
}
printf (audio_alsa_out: Got %d buffer_time, wanted
%d\n,buffer_time, BUFFER_TIME);
err = snd_pcm_hw_params_get_buffer_size(params, (this-buffer_size));
/* set the period time [us] (interrupt every x us|y samples ...) */
dir=0;
period_size=this-buffer_size/8;
err = snd_pcm_hw_params_set_period_size_near(this-audio_fd, params,
period_size, dir);
if (err 0) {
printf (audio_alsa_out: period time not available);
goto __close;
}
dir=0;
err = snd_pcm_hw_params_get_period_size(params, period_size, dir);
if (2*period_size this-buffer_size) {
printf (audio_alsa_out: buffer to small, could not use.
period_size=%ld, buffer_size=%ld\n, period_size, this-buffer_s
ize);
goto __close;
}
---
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
