From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: hw pause in USB Date: Tue, 13 Dec 2005 19:20:08 +0100 Message-ID: References: <439E2735.4060700@pianodisc.com> <20051213091651.GA23938@turing.informatik.uni-halle.de> <439F058D.1070600@pianodisc.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <439F058D.1070600@pianodisc.com> Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Steve deRosier Cc: Clemens Ladisch , Alsa-Devel List-Id: alsa-devel@alsa-project.org At Tue, 13 Dec 2005 09:31:57 -0800, Steve deRosier wrote: > > Takashi Iwai wrote: > > At Tue, 13 Dec 2005 10:16:51 +0100, > > Clemens Ladisch wrote: > > > >>Steve deRosier wrote: > >> > >>>When running my player via commandline and pressing pause, I get the > >>>following error message out of ALSA lib: > >>> > >>>ALSA lib pcm_hw.c:535:(snd_pcm_hw_pause) SNDRV_PCM_IOCTL_PAUSE failed: > >>>Function not implemented > >>> > >>>I'm guessing that the USB driver doesn't implement pause. > >> > >>Yes. > >> > > Perhaps it should?!? Patches are always welcome :) > >> > >>>My program implements pause by calling snd_pcm_pause( hPCM, 1 );. > >> > >>You cannot call snd_pcm_pause() when the device doesn't support it > >>(it should have returned an error code). > >>See snd_pcm_hw_params_can_pause(). > >> > >> > >>>* Is there a better way to implement pause in my client program? > >> > >>snd_pcm_stop() > > > > > > Heh, it's snd_pcm_drop() in alsa-lib :) > > > > snd_pcm_drop() will stop DMA and abandon the whole data on the ring > > buffer. To restart the stream, you have to call snd_pcm_prepare() > > and fill the rest data again (and start with snd_pcm_start() if > > necessary). > > > > So, obviously, this procedure isn't "better" than snd_pcm_pause(), > > but works with all devices as a fallback. > > > > So, do I use snd_pcm_stop() or snd_pcm_drop()? There is no snd_pcm_stop(). > Also, if > snd_pcm_drop() will abandon the data in the ringbuffer, how do I > know what it abandoned so I can put the right data back to restart? You need to track the data position. Count the data you sent and check the value of snd_pcm_delay() just before snd_pcm_drop(). > And what is the maximum amount of data it might discard? The size of the ring buffer. Can't be more, of course. > After > sending the samples to Alsa, my program doesn't normally keep track > of that data so I'll need to know how much to buffer as a "pause > undo" buffer. You need a manual track. > On a design note, shouldn't the library hide this issue from the > user? I understand the point of alsa is to provide a powerful > library for advanced apps, but most applications aren't going to > care HOW pause is implemented and exposing the fact that some > devices implement it and some don't really defeat the purpose of > having a library API in the first place. Don't take my criticism > wrong, I think Alsa is great. But, having to put this sort of > hardware based check in my code hurts. And frankly also hurts my > reputation around here since I didn't realize that snd_pcm_pause() > actually should be titled > snd_pcm_pause_if_device_supports_pause_else_burp() and I let a > release out the door with this broken (my responsibility, I > should've tested pause with USB devices; but man, who would've thunk > it would've been an issue). Yes, it's a better name. But too late to change. > Seems to me that the library should take device differences into > account and just Do The Right Thing, or that all the drivers must > support such basic functionality in decent way, even if the driver > has to simulate in software a feature the hardware can't support (if > that is indeed the case here). The problem behind the pause is that many hardware doesn't support the pause function indeed. You can stop the stream, but not restart from the exact position. Hence, the driver needs to set up the whole data again. Now if the library does it secretly, it will cause an inconsistency between the actual data on the driver and the application side. The app still holds the old data while the actual position was reset to zero by the restart. So, it's not always good to hide everyhing in alsa-lib. > Again, don't take me to be too harsh. I'm just trying to stimulate > positive discussion so we can improve alsa if warranted in this > case. I'll even help w/ the patches if: 1. we can agree on what > needs to be done and 2. if someone can point me to where > (file/function) it needs to be fixed. Well, as I mentioned many times, I don't recommend to use alsa-lib directly with audio apps at all. Rather, I see it as a lowlevel backend like X11 library (do you remember different visual models on X?) What we need is a nice and portable library for simplistic usages to cover different hardwares for a specific purpose. Of course, it could be a part of alsa-lib, but it's not necessary to be, too. Though, I guess it's still doable without too much hustle to make snd_pcm_pause() emulation in alsa-lib. But, enabling it unconditionally looks too much to me. Takashi ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click