bugDenemo - Bugs: bug #43439, Audio error spam

 
 

bug #43439: Audio error spam

Submitter:  Éloi Rivard <eloi>
Submitted:  Sun 19 Oct 2014 07:35:36 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 11 Jan 2016 05:29:12 PM UTC, comment #12: 

fixed in 2.0.1 (at least, I no longer see them!)

Richard Shann <rshann>
Group administrator
Wed 22 Oct 2014 09:33:08 PM UTC, comment #11: 

I just realized I did not explained that I see the pthread_join error each time, and only when I get the underrun errors. Both errors are fixed with PULSE_LATENCY_MSEC too. They seem related.

Éloi Rivard <eloi>
Group Member
Mon 20 Oct 2014 09:52:47 AM UTC, comment #10: 

Well, it was worth checking all that. The chances are now that it is the Alsa which is asking for data too often (could this be a system setup or the way portaudio sets Alsa up?)

Richard Shann <rshann>
Group administrator
Mon 20 Oct 2014 09:40:54 AM UTC, comment #9: 

Max Recording Time was already set to 0.

I still get the error messages when I configure denemo with --disable-rubberband .

I growed OUTPUT_BUFFER_SIZE until 65536, and it did not solved the issue.

Éloi Rivard <eloi>
Group Member
Mon 20 Oct 2014 07:59:03 AM UTC, comment #8: 


2) There is a return statement in the middle of a function at line 75.
So the rest of the function is dead code.
Yes - it says that it is for output to a MIDI device, we should perhaps delete the code until someone wants it - as the comment says it would then need work doing to it.



>The underrun is probably because data is not being delivered to >the ALSA
>driver in time. Increasing the latency can certainly help that. >The
>problem may be because you are doing too much work in the >callback routine.


If you have Max Recording Time set 0 it will be worth looking for other heavy activity - I intended all such to be off by default, e.g. the rubberband code should not get activated by default.

>Or the buffers are too small.


It would be worthwhile testing out different buffer sizes

Richard Shann <rshann>
Group administrator
Mon 20 Oct 2014 07:53:45 AM UTC, comment #7: 

The comment about stream_callback() (in portaudio.c) doing heavy work is valid; set Edit->Change Preferences->Audio->Max Recording Time to 0
and that will disable this code. I think this field defaults to zero, but we should make that explicit.

Richard Shann <rshann>
Group administrator
Mon 20 Oct 2014 12:54:49 AM UTC, comment #6: 

The discussion on the portaudio mailing list.

http://music.columbia.edu/pipermail/portaudio/2014-October/016345.html

Éloi Rivard <eloi>
Group Member
Sun 19 Oct 2014 09:01:07 PM UTC, comment #5: 

Or maybe it is because we do not use correctly the library, I don't know.

Playing with the latency parameter of Pm_OpenOutput did not give results.

http://portmedia.sourceforge.net/portmidi/doxygen/group__grp__device.html

Maybe we should ask the PortMidi people.

Éloi Rivard <eloi>
Group Member
Sun 19 Oct 2014 08:25:06 PM UTC, comment #4: 

This pthread_join hanging on exit is something I see quite often, looking at your back trace it would seem that the portaudio library is at fault, but whether that is really the case I don't know.

Richard Shann <rshann>
Group administrator
Sun 19 Oct 2014 08:04:44 PM UTC, comment #3: 

I can fix this by using this environment var:
PULSE_LATENCY_MSEC=30
export PULSE_LATENCY_MSEC

But I think it is a bit dirty.

Éloi Rivard <eloi>
Group Member
Sun 19 Oct 2014 07:50:54 PM UTC, comment #2: 

Yes I am talking about a continuous stream. The audio-backend is PortAudio. I am also using the default configure.

This also seems to prevent denemo from quitting (I have to Ctrl-C it):

Denemo - MESSAGE : That's it, I quit!
[Thread 0x7fffec634700 (LWP 26281) exited]
Denemo - MESSAGE : Destroying PortAudio backend
^C
Program received signal SIGINT, Interrupt.
0x00000038d0e09237 in pthread_join (threadid=140737018586880, thread_return=thread_return@entry=0x7fffffffcc30) at pthread_join.c:92
92     lll_wait_tid (pd->tid);
(gdb) bt
#0  0x00000038d0e09237 in pthread_join (threadid=140737018586880, thread_return=thread_return@entry=0x7fffffffcc30) at pthread_join.c:92
#1  0x00000038e8c1bc5f in PaUnixThread_Terminate (self=self@entry=0x14e9440, wait=<optimized out>, exitResult=exitResult@entry=0x7fffffffcc64) at src/os/unix/pa_unix_util.c:441
#2  0x00000038e8c10005 in RealStop (stream=0x14e92a0, abort=<optimized out>) at src/hostapi/alsa/pa_linux_alsa.c:3062
#3  0x00000038e8c08bdd in Pa_CloseStream (stream=<optimized out>) at src/common/pa_front.c:1351
#4  0x00000000004d691d in portaudio_destroy () at audio/portaudiobackend.c:327
#5  0x00000000004d4c09 in destroy (backend=AUDIO_BACKEND) at audio/audiointerface.c:277
#6  audio_shutdown () at audio/audiointerface.c:300
#7  0x0000000000477980 in close_gui_with_check (action=action@entry=0x0, param=param@entry=0x0) at core/view.c:1040
#8  0x000000000047799d in delete_callback (widget=<optimized out>, event=<optimized out>) at core/view.c:890
#9  0x00000030e3db6dfe in _gtk_marshal_BOOLEAN__BOXEDv (closure=0x1500f70, return_value=0x7fffffffce20, instance=<optimized out>, args=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x7c5870)
    at gtkmarshalers.c:130
#10 0x00000030df010747 in _g_closure_invoke_va (closure=closure@entry=0x1500f70, return_value=return_value@entry=0x7fffffffce20, instance=instance@entry=0xa74600, args=args@entry=0x7fffffffcf20, n_params=1, param_types=0x7c5870)
    at gclosure.c:831
#11 0x00000030df0299d7 in g_signal_emit_valist (instance=0xa74600, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffcf20) at gsignal.c:3215
#12 0x00000030df02a63f in g_signal_emit (instance=instance@entry=0xa74600, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3363
#13 0x00000030e3eee50c in gtk_widget_event_internal (widget=widget@entry=0xa74600 [GtkWindow], event=event@entry=0x3da35c0) at gtkwidget.c:7229
#14 0x00000030e3eee7e9 in gtk_widget_event (widget=widget@entry=0xa74600 [GtkWindow], event=event@entry=0x3da35c0) at gtkwidget.c:6891
#15 0x00000030e3db6308 in gtk_main_do_event (event=0x3da35c0) at gtkmain.c:1617
#16 0x00000030e444ffb2 in gdk_event_source_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at gdkeventsource.c:364
#17 0x00000030dec49c3a in g_main_dispatch (context=0x7e99e0) at gmain.c:3064
#18 g_main_context_dispatch (context=context@entry=0x7e99e0) at gmain.c:3663
#19 0x00000030dec49f88 in g_main_context_iterate (context=0x7e99e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3734
#20 0x00000030dec4a25a in g_main_loop_run (loop=0x228a8a0) at gmain.c:3928
#21 0x00000030e3db55d5 in gtk_main () at gtkmain.c:1192
#22 0x0000000000475c24 in inner_main (files=0x0) at core/view.c:705
#23 0x00000038d3a5c71a in c_body (d=0x7fffffffd5e0) at continuations.c:517
#24 0x00000038d3af1e89 in vm_regular_engine (vm=<optimized out>, program=0xd8c000, argv=<optimized out>, nargs=2) at vm-i-system.c:858
#25 0x00000038d3a66323 in scm_call_4 (proc=0xe70c30, arg1=arg1@entry=0x404, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>) at eval.c:507
#26 0x00000038d3adbbd9 in scm_catch_with_pre_unwind_handler (key=key@entry=0x404, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:73
#27 0x00000038d3adbcdf in scm_c_catch (tag=tag@entry=0x404, body=body@entry=0x38d3a5c710 <c_body>, body_data=body_data@entry=0x7fffffffd5e0, handler=handler@entry=0x38d3a5cb30 <c_handler>, handler_data=handler_data@entry=0x7fffffffd5e0,
    pre_unwind_handler=pre_unwind_handler@entry=0x38d3a5c8c0 <pre_unwind_handler>, pre_unwind_handler_data=pre_unwind_handler_data@entry=0xe16ff0) at throw.c:207
#28 0x00000038d3a5ceaf in scm_i_with_continuation_barrier (body=body@entry=0x38d3a5c710 <c_body>, body_data=body_data@entry=0x7fffffffd5e0, handler=handler@entry=0x38d3a5cb30 <c_handler>, handler_data=handler_data@entry=0x7fffffffd5e0,
    pre_unwind_handler=pre_unwind_handler@entry=0x38d3a5c8c0 <pre_unwind_handler>, pre_unwind_handler_data=0xe16ff0) at continuations.c:455
#29 0x00000038d3a5cf95 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:551
#30 0x00000038d3ad934c in with_guile_and_parent (base=base@entry=0x7fffffffd640, data=data@entry=0x7fffffffd670) at threads.c:906
#31 0x00000038e8815e62 in GC_call_with_stack_base (fn=fn@entry=0x38d3ad9300 <with_guile_and_parent>, arg=arg@entry=0x7fffffffd670) at misc.c:1553
#32 0x00000038d3ad9748 in scm_i_with_guile_and_parent (parent=<optimized out>, data=0x0, func=<optimized out>) at threads.c:949
#33 scm_with_guile (func=<optimized out>, data=data@entry=0x0) at threads.c:955
#34 0x00000000004153f0 in main (argc=1, argv=0x7fffffffd7e8) at core/main.c:469
(gdb)

Éloi Rivard <eloi>
Group Member
Sun 19 Oct 2014 07:44:45 PM UTC, comment #1: 


Which audio backends do you have configured/in use?

By "hundreds" do you mean a continuous streamn of error messages?

I see one of these when starting up, and another each time I pause the program using Ctrl-C under gdb and then continue. I am using the default configure.

Richard Shann <rshann>
Group administrator
Sun 19 Oct 2014 07:35:36 PM UTC, original submission:  

Since several months, denemo throws hundreds of audio error messages (I cannot remember since when, I just live with it):

ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred

This happens on Fedora 21 (64bits).

This should be investigated.

Éloi Rivard <eloi>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rshann (Posted a comment)
  • -email is unavailable- added by eloi (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-01-11 rshann StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2014-10-20 rshann StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code