From: Jeff W. <we...@ya...> - 2005-10-09 23:08:42
|
0.21-03 is up on sourceforge today. A few bugfixes. ALSA playback was improved (and hopefully OSS playback wasn't degraded). Thanks John Cirillo for noticing the playback problem. There is code for OSX, but as yet no formal mechanism for compiling/linking on OSX. Enjoy. Jeff |
From: Johan De G. <joh...@sk...> - 2005-11-02 20:33:21
|
Hello, Those changes to the alsa code made me hope, but I don't notice anything of a change. Used the last source from sourceforge 0.21-03. - running under Gentoo 2.6.12 alsa 1.0.9 - ./configure --enable-alsa - changed the "-mcpu=x86_64 -march=x86_64" to "-mcpu=k8 -march=k8" in order to compile on a 64bit Opteron system - "make" and "make install" I can open it fine, load a file, make a selection etc. But if I hit playback I get: ... ########################################################## audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update Broken pipe audio_device_processed_bytes: snd_pcm_delay Broken pipe ########################################################## audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update Broken pipe audio_device_processed_bytes: snd_pcm_delay Broken pipe ... Once this message starts sound stops and so does the cursor. Until I stop playback this message keeps coming in the terminal. The time to get this is variable, but never longer than a few seconds (15 at most). Gwc doesn't crash, and alsa continues as well. Hitting playback again will restart the selection, until "it" happens again. Anything that I can do to get this running, but I don't know the first thing about programming let alone debugging. If you need more specific info, files, have me run some tests,etc just ask. But I don't know anything about it, so I won't find it myself if no-one educates me on it. Since this is the only application for audio restoration... regards, Johan De Groote On Sunday 09 October 2005 23:10, Jeff Welty wrote: > 0.21-03 is up on sourceforge today. A few bugfixes. ALSA playback was > improved > (and hopefully OSS playback wasn't degraded). Thanks John Cirillo for > noticing the > playback problem. > > There is code for OSX, but as yet no formal mechanism for > compiling/linking on OSX. > > Enjoy. > Jeff > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Gwc-general mailing list > Gwc...@li... > https://lists.sourceforge.net/lists/listinfo/gwc-general > > |
From: Jeff W. <we...@ya...> - 2005-11-06 14:06:34
|
Does playback still sound good? If so I wouldn't worry about the warnings coming to the terminal, those are generated by GWC itself, not ALSA or the kernel. I'd still like to understand more about ALSA, but I'm afraid it will be a while before I get enough time to look into it thoroughly. If, however, playback doesn't sound good, then I'll make time to look at this more closely. Cheers, Jeff Johan De Groote wrote: >Hello, > >Those changes to the alsa code made me hope, but I don't notice anything of a >change. Used the last source from sourceforge 0.21-03. > >- running under Gentoo 2.6.12 alsa 1.0.9 >- ./configure --enable-alsa >- changed the "-mcpu=x86_64 -march=x86_64" to "-mcpu=k8 -march=k8" in order to >compile on a 64bit Opteron system >- "make" and "make install" > >I can open it fine, load a file, make a selection etc. But if I hit playback I >get: > >... >########################################################## >audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >Broken pipe >audio_device_processed_bytes: snd_pcm_delay Broken pipe >########################################################## >audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >Broken pipe >audio_device_processed_bytes: snd_pcm_delay Broken pipe >... > >Once this message starts sound stops and so does the cursor. Until I stop >playback this message keeps coming in the terminal. The time to get this is >variable, but never longer than a few seconds (15 at most). Gwc doesn't >crash, and alsa continues as well. Hitting playback again will restart the >selection, until "it" happens again. > >Anything that I can do to get this running, but I don't know the first thing >about programming let alone debugging. If you need more specific info, files, >have me run some tests,etc just ask. But I don't know anything about it, so I >won't find it myself if no-one educates me on it. > >Since this is the only application for audio restoration... > >regards, >Johan De Groote > >On Sunday 09 October 2005 23:10, Jeff Welty wrote: > > >>0.21-03 is up on sourceforge today. A few bugfixes. ALSA playback was >>improved >>(and hopefully OSS playback wasn't degraded). Thanks John Cirillo for >>noticing the >>playback problem. >> >>There is code for OSX, but as yet no formal mechanism for >>compiling/linking on OSX. >> >>Enjoy. >>Jeff >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: >>Power Architecture Resource Center: Free content, downloads, discussions, >>and more. http://solutions.newsforge.com/ibmarch.tmpl >>_______________________________________________ >>Gwc-general mailing list >>Gwc...@li... >>https://lists.sourceforge.net/lists/listinfo/gwc-general >> >> >> >> > > >------------------------------------------------------- >SF.Net email is sponsored by: >Tame your development challenges with Apache's Geronimo App Server. Download >it for free - -and be entered to win a 42" plasma tv or your very own >Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >_______________________________________________ >Gwc-general mailing list >Gwc...@li... >https://lists.sourceforge.net/lists/listinfo/gwc-general > > > >!DSPAM:43692934155842084318266! > > |
From: Jeff W. <we...@ya...> - 2005-11-06 17:47:42
|
OK. I'll put understanding ALSA at the top of my reading list :-) Anyone else have any clues? In the meantime Johan, you might try configuring gwc, but without the --enable-alsa flag. That will cause GWC to use the old OSS interface, which ALSA emulates. That may work just fine I ran it that way on my Fedora Core 1 box for a long time, but there can be reasons why it might work for me and not for you (primarily the soundcard driver), you'd just have to try it. Good luck. Keep us informed so we can help you. I believe understanding what is happening to you and fixing it will make GWC better for everyone! Thanks, Jeff Johan De Groote wrote: >Hello, > >No, when the messages come, playback stops. There is no sound anymore. The >cursor also freezes. If you stop the playback and then restart it, it works >again (sound and cursor movement) until the messages come. It lasts at most >about 20 seconds. > >Best regards, >Johan > >On Sunday 06 November 2005 14:07, you wrote: > > >>Does playback still sound good? If so I wouldn't worry about >>the warnings coming to the terminal, those are generated by GWC >>itself, not ALSA or the kernel. >> >>I'd still like to understand more about ALSA, but I'm afraid it >>will be a while before I get enough time to look into it thoroughly. >> >>If, however, playback doesn't sound good, then I'll make time to >>look at this more closely. >> >>Cheers, >>Jeff >> >>Johan De Groote wrote: >> >> >> >>>Hello, >>> >>>Those changes to the alsa code made me hope, but I don't notice anything of >>> >>> >a > > >>>change. Used the last source from sourceforge 0.21-03. >>> >>>- running under Gentoo 2.6.12 alsa 1.0.9 >>>- ./configure --enable-alsa >>>- changed the "-mcpu=x86_64 -march=x86_64" to "-mcpu=k8 -march=k8" in order >>> >>> >to > > >>>compile on a 64bit Opteron system >>>- "make" and "make install" >>> >>>I can open it fine, load a file, make a selection etc. But if I hit >>> >>> >playback I > > >>>get: >>> >>>... >>>########################################################## >>>audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >>>Broken pipe >>>audio_device_processed_bytes: snd_pcm_delay Broken pipe >>>########################################################## >>>audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >>>Broken pipe >>>audio_device_processed_bytes: snd_pcm_delay Broken pipe >>>... >>> >>>Once this message starts sound stops and so does the cursor. Until I stop >>>playback this message keeps coming in the terminal. The time to get this is >>>variable, but never longer than a few seconds (15 at most). Gwc doesn't >>>crash, and alsa continues as well. Hitting playback again will restart the >>>selection, until "it" happens again. >>> >>>Anything that I can do to get this running, but I don't know the first >>> >>> >thing > > >>>about programming let alone debugging. If you need more specific info, >>> >>> >files, > > >>>have me run some tests,etc just ask. But I don't know anything about it, so >>> >>> >I > > >>>won't find it myself if no-one educates me on it. >>> >>>Since this is the only application for audio restoration... >>> >>>regards, >>>Johan De Groote >>> >>>On Sunday 09 October 2005 23:10, Jeff Welty wrote: >>> >>> >>> >>> >>>>0.21-03 is up on sourceforge today. A few bugfixes. ALSA playback was >>>>improved >>>>(and hopefully OSS playback wasn't degraded). Thanks John Cirillo for >>>>noticing the >>>>playback problem. >>>> >>>>There is code for OSX, but as yet no formal mechanism for >>>>compiling/linking on OSX. >>>> >>>>Enjoy. >>>>Jeff >>>> >>>> >>>>------------------------------------------------------- >>>>This SF.Net email is sponsored by: >>>>Power Architecture Resource Center: Free content, downloads, discussions, >>>>and more. http://solutions.newsforge.com/ibmarch.tmpl >>>>_______________________________________________ >>>>Gwc-general mailing list >>>>Gwc...@li... >>>>https://lists.sourceforge.net/lists/listinfo/gwc-general >>>> >>>> >>>> >>>> >>>> >>>> >>>------------------------------------------------------- >>>SF.Net email is sponsored by: >>>Tame your development challenges with Apache's Geronimo App Server. >>> >>> >Download > > >>>it for free - -and be entered to win a 42" plasma tv or your very own >>>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >>>_______________________________________________ >>>Gwc-general mailing list >>>Gwc...@li... >>>https://lists.sourceforge.net/lists/listinfo/gwc-general >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> > > > |
From: James T. <ja...@ta...> - 2005-11-11 16:40:05
|
On Wednesday 02 November 2005 21:51, Johan De Groote wrote: JD> I can open it fine, load a file, make a selection etc. But if I hit playback I JD> get: JD> JD> ... JD> ########################################################## JD> audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update JD> Broken pipe JD> audio_device_processed_bytes: snd_pcm_delay Broken pipe JD> ########################################################## JD> audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update JD> Broken pipe JD> audio_device_processed_bytes: snd_pcm_delay Broken pipe JD> ... JD> JD> Once this message starts sound stops and so does the cursor. Until I stop JD> playback this message keeps coming in the terminal. The time to get this is JD> variable, but never longer than a few seconds (15 at most). Gwc doesn't JD> crash, and alsa continues as well. Hitting playback again will restart the JD> selection, until "it" happens again. JD> Hi, I'm back! I think I'm making some progress on this one (which seems to be a similar problem to one I was having a while back (April 04) [only then it wasn't possible to stop it]. snd_pcm_avail_update() returns -EPIPE if the output buffer has emptied, and the driver has tried to get some data. Because audio_device_nonblocking_write_buffer_size() bails out on any error, the buffer never gets filled so it goes into an infinite loop. I think that the answer is at least in part to modify audio_alsa.c, so that a "broken pipe error is effectively ignored (patch at the end) -- it could be rearranged to eliminate the message altogether but I was trying to see what influenced the problem. The other things that may help are to increase the buffer size (in audio_device.h) [BTW there is a redundant redefinition of MAXBUFSIZE in audio_util.c which ought to be removed.] and not popping windows or generally doing too much with X while playing back. James P.S. I've changed distro yet again -- Kubuntu now. ++ BEGIN PATCH ++ *** audio_alsa.c 2005-11-11 16:28:08.000000000 +0000 --- audio_alsa.c~ 2005-11-11 15:57:50.000000000 +0000 *************** *** 267,273 **** if (frames < 0) { perr("audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update", frames); ! if (frames != -EPIPE ) return 0; } len = snd_pcm_frames_to_bytes(handle, frames); --- 267,273 ---- if (frames < 0) { perr("audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update", frames); ! return 0; } len = snd_pcm_frames_to_bytes(handle, frames); ++END PATCH++ As far as I can tell -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |
From: James T. <ja...@ta...> - 2005-11-11 17:17:18
|
Just one other comment: it appears that the makefile fails to have included files as dependencies, so changing audio_device.h or audio_alsa.c doesn't cause a rebuild on a simple "make". I'm not familiar enough with autotools to know if there's an easy fix for this. James -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |
From: Jeff W. <we...@ya...> - 2005-11-12 15:48:17
Attachments:
audio_alsa.c
Makefile.fix
|
Hi James, Good to hear from you! I've been reading a little on ALSA this pase week, and it looks like not handling the EPIPE error is behind some of GWC's troubles. I was showing the "broken pipe" errors consistently at the end of a playback section -- because the playback cursor lags a few milliseconds behind the audio playback, and the call to snd_pcm_delay in function audio_device_processed_bytes would give the EPIPE when the audio_buffer had already emptied. This does not affect playback sound quality, but I have trapped that error. I took your thought here about the EPIPE in the nonblocking_write_buffersize call and added one tweak -- attempt recover the sound device handle before failing. Attached is my current audio_alsa.c (which changed the function perr to snd_perr, and recover_write to recover_snd_handle.) See how this works. Johan, let us know. I think there is still problems with the audio buffer size, and when playback starts there will be a message on the console, if you could tell us what it says: "ALSA audio_device_best_buffer_size:xxxx (frames:xxxx)" --- For the Makefile problem, if you will insert the lines from Makefile.fix indicated below, it will pick up changes to the audio src. You can put these lines into Makefile.in as well and then "configure" will build the right Makefile. I'd just send my Makefile but I don't know what other options you may or may not have. Be sure for the indents that it is a single tab, or make won't work properly. ############### Changes for Makefile #################################### gwc : $(OBJS) meschach.a $(CC) $(OBJS) $(EFENCE) $(LFLAGS) $(LIBS) -o gwc ==> ==> audio_device.o : audio_device.c audio_alsa.c audio_oss.c audio_osx.c ==> $(COMPILE) -c audio_device.c .c.o : $(COMPILE) -c $< ##################################################################### Cheers, Jeff James Tappin wrote: >On Wednesday 02 November 2005 21:51, Johan De Groote wrote: >JD> I can open it fine, load a file, make a selection etc. But if I hit > playback I JD> get: >JD> >JD> ... >JD> ########################################################## >JD> audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >JD> Broken pipe >JD> audio_device_processed_bytes: snd_pcm_delay Broken pipe >JD> ########################################################## >JD> audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >JD> Broken pipe >JD> audio_device_processed_bytes: snd_pcm_delay Broken pipe >JD> ... >JD> >JD> Once this message starts sound stops and so does the cursor. Until I stop >JD> playback this message keeps coming in the terminal. The time to get this > is JD> variable, but never longer than a few seconds (15 at most). Gwc > doesn't JD> crash, and alsa continues as well. Hitting playback again will > restart the JD> selection, until "it" happens again. >JD> > >Hi, I'm back! > >I think I'm making some progress on this one (which seems to be a similar >problem to one I was having a while back (April 04) [only then it wasn't >possible to stop it]. snd_pcm_avail_update() returns -EPIPE if the output >buffer has emptied, and the driver has tried to get some data. Because >audio_device_nonblocking_write_buffer_size() bails out on any error, the >buffer never gets filled so it goes into an infinite loop. I think that the >answer is at least in part to modify audio_alsa.c, so that a "broken pipe >error is effectively ignored (patch at the end) -- it could be rearranged to >eliminate the message altogether but I was trying to see what influenced the >problem. > >The other things that may help are to increase the buffer size (in >audio_device.h) [BTW there is a redundant redefinition of MAXBUFSIZE in >audio_util.c which ought to be removed.] and not popping windows or generally >doing too much with X while playing back. > >James > >P.S. I've changed distro yet again -- Kubuntu now. > >++ BEGIN PATCH ++ >*** audio_alsa.c 2005-11-11 16:28:08.000000000 +0000 >--- audio_alsa.c~ 2005-11-11 15:57:50.000000000 +0000 >*************** >*** 267,273 **** > if (frames < 0) { > perr("audio_device_nonblocking_write_buffer_size: >snd_pcm_avail_update", > frames); >! if (frames != -EPIPE ) return 0; > } > len = snd_pcm_frames_to_bytes(handle, frames); > >--- 267,273 ---- > if (frames < 0) { > perr("audio_device_nonblocking_write_buffer_size: >snd_pcm_avail_update", > frames); >! return 0; > } > len = snd_pcm_frames_to_bytes(handle, frames); > ++END PATCH++ > > >As far as I can tell > > |
From: Jeff W. <we...@ya...> - 2005-11-15 00:08:04
|
That is good news Johan. Thanks for being willing to test this out. Now it looks like the problem is the buffer size GWC is using for ALSA is too small (512 bytes), which is probably the reason for the remaining errors. I'll tackle that next. Cheers, Jeff Johan De Groote wrote: >Hello Jeff, > >Took a bit longer as expected, but we had a long weekend so I hardly saw the >pc. > >Started wih a clean copy of the code, then replaced the alsa.c by the one you >send and spliced in the makefile.fix in makefile.in. Used "./configure >--enable-alsa" like the previous time. > >Issueing "make" still gives the old problem of "x86-64" not being recognised. >But once I change that to "k8" in the Makefile it compiles cleanly. > >The change is enormous! Playback doesn't stop anymore, it plays the whole >selection. There are still errors, but they do not always give an audible >"disturbance". Sometimes you get a slight click but nothing more than you >would expect from an LP recording (and much less than on some LPs). I have >not yet tried to check if the click comes with the underrun or the other >message. > >I played a 20 second selection, and below is the output to the terminal. > >Thanks, >Johan > >[Terminal output] >daw gwc-0.21-03 # gwc >Current stack limit: 8388608 bytes >ALSA audio_device_best_buffer_size:512 (frames:128) >########################################################## >audio_device_processed_bytes: ALSA buffer underrun >Broken pipe >########################################################## >audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >Broken pipe >########################################################## >audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >Broken pipe >########################################################## >audio_device_processed_bytes: ALSA buffer underrun >Broken pipe >########################################################## >audio_device_processed_bytes: ALSA buffer underrun >Broken pipe >########################################################## >audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >Broken pipe >########################################################## >audio_device_processed_bytes: ALSA buffer underrun >Broken pipe >########################################################## >audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >Broken pipe >########################################################## >audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >Broken pipe >########################################################## >audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >Broken pipe >########################################################## >audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >Broken pipe >########################################################## >audio_device_processed_bytes: ALSA buffer underrun >Broken pipe > >Stop playback with playback_samples_remaining:0 >########################################################## >audio_device_processed_bytes: ALSA buffer underrun >Broken pipe >Closing the ALSA audio device >[end terminal output] > >On Saturday 12 November 2005 15:49, you wrote: > > >>Hi James, >> >>Good to hear from you! >> >>I've been reading a little on ALSA this pase week, and it looks like not >>handling >>the EPIPE error is behind some of GWC's troubles. I was showing the >>"broken pipe" >>errors consistently at the end of a playback section -- because the playback >>cursor lags a few milliseconds behind the audio playback, and the call to >>snd_pcm_delay in function audio_device_processed_bytes would give the >>EPIPE when the audio_buffer had already emptied. This does not affect >>playback >>sound quality, but I have trapped that error. >> >>I took your thought here about the EPIPE in the >>nonblocking_write_buffersize call >>and added one tweak -- attempt recover the sound device handle before >>failing. >> >>Attached is my current audio_alsa.c (which changed the function perr to >>snd_perr, >>and recover_write to recover_snd_handle.) See how this works. Johan, >>let us know. >>I think there is still problems with the audio buffer size, and when >>playback starts >>there will be a message on the console, if you could tell us what it says: >> >> "ALSA audio_device_best_buffer_size:xxxx (frames:xxxx)" >> >>--- >>For the Makefile problem, if you will insert the lines from Makefile.fix >>indicated below, >>it will pick up changes to the audio src. You can put these lines into >>Makefile.in as well >>and then "configure" will build the right Makefile. I'd just send my >>Makefile but I don't >>know what other options you may or may not have. Be sure for the >>indents that it is a single >>tab, or make won't work properly. >> >>############### Changes for Makefile #################################### >> >>gwc : $(OBJS) meschach.a >> $(CC) $(OBJS) $(EFENCE) $(LFLAGS) $(LIBS) -o gwc >>==> >>==> audio_device.o : audio_device.c audio_alsa.c audio_oss.c audio_osx.c >>==> $(COMPILE) -c audio_device.c >> >>.c.o : >> $(COMPILE) -c $< >> >>##################################################################### >> >>Cheers, >>Jeff >> >>James Tappin wrote: >> >> >> >>>On Wednesday 02 November 2005 21:51, Johan De Groote wrote: >>>JD> I can open it fine, load a file, make a selection etc. But if I hit >>>playback I JD> get: >>>JD> >>>JD> ... >>>JD> ########################################################## >>>JD> audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >>>JD> Broken pipe >>>JD> audio_device_processed_bytes: snd_pcm_delay Broken pipe >>>JD> ########################################################## >>>JD> audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update >>>JD> Broken pipe >>>JD> audio_device_processed_bytes: snd_pcm_delay Broken pipe >>>JD> ... >>>JD> >>>JD> Once this message starts sound stops and so does the cursor. Until I >>> >>> >stop > > >>>JD> playback this message keeps coming in the terminal. The time to get >>> >>> >this > > >>>is JD> variable, but never longer than a few seconds (15 at most). Gwc >>>doesn't JD> crash, and alsa continues as well. Hitting playback again will >>>restart the JD> selection, until "it" happens again. >>>JD> >>> >>>Hi, I'm back! >>> >>>I think I'm making some progress on this one (which seems to be a similar >>>problem to one I was having a while back (April 04) [only then it wasn't >>>possible to stop it]. snd_pcm_avail_update() returns -EPIPE if the output >>>buffer has emptied, and the driver has tried to get some data. Because >>>audio_device_nonblocking_write_buffer_size() bails out on any error, the >>>buffer never gets filled so it goes into an infinite loop. I think that the >>>answer is at least in part to modify audio_alsa.c, so that a "broken pipe >>>error is effectively ignored (patch at the end) -- it could be rearranged >>> >>> >to > > >>>eliminate the message altogether but I was trying to see what influenced >>> >>> >the > > >>>problem. >>> >>>The other things that may help are to increase the buffer size (in >>>audio_device.h) [BTW there is a redundant redefinition of MAXBUFSIZE in >>>audio_util.c which ought to be removed.] and not popping windows or >>> >>> >generally > > >>>doing too much with X while playing back. >>> >>>James >>> >>>P.S. I've changed distro yet again -- Kubuntu now. >>> >>>++ BEGIN PATCH ++ >>>*** audio_alsa.c 2005-11-11 16:28:08.000000000 +0000 >>>--- audio_alsa.c~ 2005-11-11 15:57:50.000000000 +0000 >>>*************** >>>*** 267,273 **** >>> if (frames < 0) { >>> perr("audio_device_nonblocking_write_buffer_size: >>>snd_pcm_avail_update", >>> frames); >>>! if (frames != -EPIPE ) return 0; >>> } >>> len = snd_pcm_frames_to_bytes(handle, frames); >>> >>>--- 267,273 ---- >>> if (frames < 0) { >>> perr("audio_device_nonblocking_write_buffer_size: >>>snd_pcm_avail_update", >>> frames); >>>! return 0; >>> } >>> len = snd_pcm_frames_to_bytes(handle, frames); >>>++END PATCH++ >>> >>> >>>As far as I can tell >>> >>> >>> >>> >> >> > > > |