[Blink] Blink for Linux hangs on second call when using PulseAudio input device

Jeff Pyle jeff at ugnd.org
Mon Jan 14 14:10:34 CET 2019


Unfortunately the programming is a bit over my head but I was able so solve
my problem with an ALSA loopback device [1].  The modified the full example
in the link from two subdevices to one, changed to 48khz, and Blink handles
it like a champ.

 [1] -
https://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge


- Jeff


On Wed, Jan 9, 2019 at 11:25 AM Dan Pascu <dan at ag-projects.com> wrote:


On 9 Jan 2019, at 14:41, Jeff Pyle wrote:

> Dan,
>
> Ok.  Can you point me to where in the Blink scripts it creates the audio
device?  I'd like to see exactly what it's doing, as well as try to get
some Pulse logs to see if I can make any sense of it.

python-sipsimple/deps/pjsip/pjmedia/src/pjmedia-audiodev/alsa_dev.c

>
>
> - Jeff
>
>
> On Wed, Jan 9, 2019 at 6:34 AM Dan Pascu <dan at ag-projects.com> wrote:
> I have used blink with pulse audio in the past (approximately 1.5-2 years
ago) and it worked (except messing up echo cancelation but that is another
story), so this may be an issue with newer ALSA/Pulse Audio.
>
> What I can tell you for sure though is that Blink doesn't use Pulse Audio
directly. Blink only uses ALSA and when you run Pulse Audio on the system,
it installs a pulse device in ALSA and makes it the system default one, so
that is how blink ends up using Pulse Audio. So I'd say that the problem
lies somewhere in the interface between Pulse Audio and ALSA.
>
> On 9 Jan 2019, at 4:55, Jeff Pyle wrote:
>
> > Hello,
> >
> > I'm running Blink for Linux 3.1.0 on Arch Linux x86_64 with PulseAudio
12.2.
> >
> > The subject describes the problem.  The first call works fine.  Once
the first call terminates, Blink can no longer place or receive a second
call...usually.  On my last last test, I got a second call dialed but not a
third call.  Looking at pjsip_trace.txt (attached), there are no entries
for my third call so something must have hung at the end of the second call.
> >
> > By 'hang', I mean the SIP stack stops responding.  The UI is functional
until I try to place another call, at which point it freezes.
> >
> > I can only reproduce this when I have PulseAudio Sound Server selected
as the input device.
> >
> > It acts like Blink doesn't release something properly with PulseAudio
when the call finishes.  I'm watching the applications using PulseAudio in
pavucontrol.  When I have PulseAudio as only the output device, I see it
appear in the pavucontrol application list only when it's playing audio.
When a call is complete (and the hangup sound plays), Blink disappears from
the list.  When I have the input device as PulseAudio, however, Blink
persists in the application list as both a sink and a source after the call
is disconnected.  It's in this state I can't place or receive another
call.  Or, dare I say, do anything that requires sound since it seems to
completely lock up when it tries to re-access PulseAudio.
> >
> > Has anyone else experienced this?
> >
> > Before someone tells me to go straight to ALSA and bypass Pulse, know
that for my needs with Blink I need Pulse in the middle.  That may not
always be the case but for today it is.
> >
> >
> > Regards,
> > Jeff
> >
> > <pjsip_trace.txt.gz>_______________________________________________
> > Blink mailing list
> > Blink at lists.ag-projects.com
> > http://lists.ag-projects.com/mailman/listinfo/blink
>
>
> --
> Dan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ag-projects.com/pipermail/blink/attachments/20190114/33b8382a/attachment.html>


More information about the Blink mailing list