Basic Music Player Integration #3
Comments
|
So I've been looking into pjsua + pulseaudio, which would be kinda neat for integrating it with multiple sound streams from whatever sources (and mixed in whatever ways), but it's probably more trouble than it's worth. pjsua doesn't have native support for pulse, i.e. using libpulse, connecting to pulse server(s), creating sinks and individual playback streams there, controlling whatever parameters - nothing of the sort, only works with sound devices through portaudio lib, which uses either ALSA or OSS on linux. Strictly one playback_dev + one capture_dev from there at a time, so one can forget about feeding sound from these "proper" sources for e.g. #5. But pjsua can also just play stuff from wav, and record to wav, and assuming it's not too smart about it, one can always put a fifo (as in mkfifo) in place of a wav (or - worst-case - a trivial FUSE layer to "emulate" wav or patch the smart bits out), and feed stuff there from whatever software audio mixer or player. pj* itself has internal plumbing for audo - conference bridges/slots, so once audio is fed into pjsua, it can multiplex it to whatever callers via that. mpd has "fifo" output plugin, so that's probably How It Should Be Done. #5 in this case becomes "multiple wav-fifo inputs from multiple players in diff conference bridges", #4 is just a matter of running a script or a cron job to occasionally switch tracks/streams in players, and #6 can probably be based on any existing mpd webui, adding knobs to also control paging.py there. |
Cheers. |
|
Actually, one more important thing to mention is that PortAudio has JACK support. Problem though is that whatever weird mesh of sinks and streams one can have in jack, there's still doesn't seem to be any way to configure more than one sound input from portaudio into pjsua, so not much point using that either, I guess. |
|
And there's an extensive and fairly recent (portaudio v19, 2015) third-party patch for pulse support: https://build.opensuse.org/package/view_file/home:illuusio:portaudio/portaudio/portaudio-pulseaudio-v19_20150116.patch?expand=0 Kinda cool, but same as with previous point, doesn't really matter unless one can actually send multiple streams from pulse into pjsua, which doesn't seem to be the case. Might hopefully help with segfaults runing pjsua without pasuspend here though... |
|
@mk-fg Let me try to answer your questions (sorry for the delay by the way!)
When a person calls in to make an announcement, they hear nothing, and don't need to hear or listen to anything. The user just wants to make an announcement (speak an announcement) in the store (like "I need help"), the file played is played out the speaker outputs from the computer this script runs on, and it is usually a short tone to get the listeners attention.
No, there usually will never be more than 1 person calling at any time, and callers are calling to speak, not listen.
Nope, not quite right, there is no whitelisting and usually only one caller, the caller only wants to announce over the speakers attached to the computer, not listen.
Not quite right, see prior comments.
Yeah, telephones and stuff can be confusing and silly, and the concept of this is a bit hard to explain. :)
For some of these there are proper terms, see below.
There is no term, people calling in do not listen, ever.
Caller
Paging Tone, Paging Chime or klaxon are all commonly used words to describe this sound
Radio stream
The caller hub doesn't exist, and isn't needed for our use case.
Yep, Mic would be what you could call the input audio stream from a caller.
Nope, since there is no whitelist there is no special name for it.
Definitely, I'm sure there is special terms for all this stuff that even i don't know, but I'd like to keep our terminology simple and understandable.
@thefinn93 picked pjproject, we can change away from pjproject though if needed.
SFLPhone with Rhythmbox playing background music was great, except every few hours SFLPhone would disconnect from the SIP Server and not reconnect until I restarted SFLPhone. SFLPhone is also depreciated/discontinued, and ring.cx doesn't work yet on Debian.
Yeah, pjproject does some very silly things, its tripped @thefinn93 and myself up a few times with its oddities! Comment #2
If we can just capture the output from PJSUA and have the output from PJSUA override audio on all output devices, I think thats all we need. I know PulseAudio can do this, but not sure if its better to use the experimental PulseAudio support you mentioned in Comment #3 or try to figure out how to do it with PortAudio. If you have any other questions or if I confused you at all, please ask questions, I want you to understand what this script should do 100%. Thanks! |
EDIT 2: Read first part of your message above, totally changing my mental model of the whole thing (it was WRONG, I thought people would be "listening" through calls, not output devices connected to the machine). I think pulse is indeed a viable, easy and otherwise very good option, will definitely test it here. |
|
Striken-through whole previous comment - with corrections from the first part of your comment, using pulse definitely makes a lot of sense, will check how well that PortAudio patch works. |
|
Ok, I did look into using pulse just now, and it's all kinds of bad, unfortunately. In case someone else will be going down the same road:
Conclusion is that I think it's not worth bothering with using portaudio-pulse in this state, likely won't be a viable option for months or years, and given that portaudio isn't under very active dev, I'd say it's not worth hoping for. Ideally, that special pulse thing won't be needed, as portaudio can just play through pulse's ALSA compat module, and pulse will wrap it into some stream like "ALSA plug-in [KSP.x86_64]", but I can't get it to run here either - thing just segfaults, and it's actually what prompted the guy to write that pulseaudio hostapi thing in the first place, seem to be common issue, lots of hits, no solutions, maybe not 100% though. There's plenty of quirks of ALSA API - e.g. stuff from http://0pointer.de/blog/projects/guide-to-sound-apis.html - which are likely what's causing this not to work through that emulation layer on my Arch, but if it works reliably on some Debian, guess maybe it's not that bad. Not sure what should I do about that either, doesn't sound worth debugging, nor looks to be a candidate for "fixed soon (tm)" - there's no new pj media backends in dev that I can google, wikis all recommend So that's it for pulseaudio in pjsua. |
|
Also, @danry25 I did mention on irc that pjsua's don't seem to connect two accs you gave me, here's why (hope it's not a big deal to dox them like that): Gist is Like I mentioned, both clients are online, regged just fine, can send messages, it's just calls that seem to be failing like that. Looks like a server error, or am I doing something wrong there? |
|
Actually, I think JACK might be an easier option, since it (a) has a native and old portaudio driver (b) doesn't need any extra stream mixer on top - does same stuff as pulse. Other "simple" option is pure (native, not some emu module) ALSA and dmix, I guess. Not sure how easy it is to control stuff in these, barely heard of either, since pulse seem to be used everywhere where it's not alsa, but definitely sound like a better options, given the crap above. |
|
@mk-fg sea2.callpipe.com is 404ing for all internal calls, I'll send you new SIP details on another testing server shortly. |
|
Ah, I think I grabbed one from ekiga, guess might work with one of these ;) |
|
New accounts connect fine, and I went for the JACK option. JACK is actually simplier than pulse in that it doesn't have anything wrt options, except which "input port" connect to which "output port", i.e. just a virtual breadboard with a bunch of jacks. Should work for routing calls and pjsua output, as of 0ef0e3d, just need to add the code to connect mpd to some (configurable) output and control it from the script, I guess. mpd itself should probably be started as a separate service, script will detect when there's a port for it in jack, connect to its control port, and do its stuff from there, no need to manage its lifecycle here that way. |
|
Though given that there's just one radio stream, and "control" that script does is mute/unmute (aka connect/disconnect in jack), there's no real need to run mpd - might as well be vlc, mplayer, mpv or even aplay, there's no need to "connect" to these, manage library or playlists there, and all the other stuff mpd is actually made for. |
|
But in light of other things like webui, guess might as well be mpd, which should have plenty of these already written too (though probably not for multiple instances, as suggested by #5). |
|
Should be implemented via JACK connect/disconnect for player streams as of 2f58c54. |
|
Implemented - closed, if still doesn't work, it's probably a bug. |
Between calls I'd like to have a radio stream playing for people to listen to. Here is an example radio stream I'd like to play.
When an inbound call comes in, the radio stream should be muted so that the person making said call/announcement can be heard. After the call has ended, the radio stream should be unmuted so that employees and patrons can resume listening.
I think integration with mpd would cover this need, although I am open to using a different package if it would work better or be easier to integrate.
The text was updated successfully, but these errors were encountered: