> Not really necessary to use an intermediate buffer, but won't hurt. > I'm not sure why you are using a circular buffer, though it shouldn't > hurt either. I wrote another code sometime back, to asychcronously playback data from a wav file, where I copied the contents of the wav file to a master buffer (like in this code) and then pumped data to the callback till the end of the buffer was reached. This code works fine -- I m trying to get the circular buffer to work now as part of an application I am writing that will allow realtime communication over the network between two hosts. A circular buffer thus seems like a good idea, as in the case of real time communication I wont really know how much data is going to come through the network. > so now instead of copying from the wave file, i m copying data from > > the master buffer to the circular buffer.. however, as per your > > suggestion, if i copy the data in the while loop in main, then, it > > might not always be copied between 2 consecutive callbacks, but maybe > > more, as the callbacks are asynchronous. > > Well, your computer is creating the data that the callback function is > going to send to alsa. If the callback function can fill the buffer > and send it to alsa and keep up with the play rate, then if you fill > the buffer in your main routine it will work even better. Your program > is sleeping instead of doing anything. You can put in place some kind > of interprocess communication so that they don't tread on each other in > the buffer. With any modern processor that isn't heavily loaded, I > don't think this will matter anyway. One question I had about this interprocess communication was whether we can pass more data to the callback function apart from the pcm handler. From what I can see in the ALSA libraries, the snd_async_add_pcm_handler function only allows you to pass one parameter in the form of void * private_data. > however, the hardware still does not ask for more data after > > executing the callback function about twice -- is there a way to > > flush the hardware buffer before beginning playback? I have pasted my > > code below > > > The program output would still be helpful. I implemented this a few > years ago. I'll go look at the code and see how it differs from > yours. I seem to recall that there was a sample of exactly this on the > alsa website, www.alsa-project.org. You could look at that and it > might trigger an Aha! moment. I think you re talking about the pcm.c which implements asynchronous playback which in my case works -- but it doesnt implement a circular buffer. Another query that I have regarding this is that I get a "Bad File Descriptor" error from the snd_pcm_start function, but my asynchronous playback code works despite this error -- I dont think thats the reason for this code failing, but its a mystry all the same! Here is the output of my program: i=49 > > error in starting snd pcm start err :File descriptor in bad state > > infinite loop > > inside callback, available frames = 364 > > going out of callback, ind = 1 > > infinite loop > > inside callback, available frames = 577 > > going out of callback, ind = 2 > > infinite loop > > inside callback, available frames = 790 > > underrun recovery > > error from snd_pcm_prepare is: 0 > > going out of callback, ind = 3 > > infinite loop > > infinite loop > > infinite loop > > > > Regards, Ashlesha. > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@xxxxxxxxxxxxxxxx > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
