leechcraft-azoth's jingle support is nowhere to be found

[v-fox]

am i missing something ?

[0xd34df00d]

-DENABLE_MEDIACALLS=True flag for cmake is required.

This requires QtMultimedia, though.

[DAP-DarkneSS]

@0xd34df00d , you forgot that you made me disable it because it was bugware!

[0xd34df00d]

It was mostly bugware in Qt 4.6-4.7 times when QtMultimedia sucked a lot. Now everything got a little bit better.

Anyway, it'd better be rewritten with GStreamer anyway.

[DAP-DarkneSS]

It was this year. You shouldn't misinform.

[0xd34df00d]

Probably. The advice to turn off ENABLE_MEDIACALLS is from the older Qt times though. So no misinformation :)

[DAP-DarkneSS]

Anyway the advice works so MEDIACALLS enabling will cause bugs that you
won't fix.

[0xd34df00d]

Were these bugs actually observed in opensuse builds?

[DAP-DarkneSS]

Grep your conference logs.

[v-fox]

eh, i just use builds from network repo, looks like it's disabled there. whole QtMultimedia seems like major pain in the ass, PPSSPP, otherwise almost fully functional PSP emulator, is unusable on Linux because devs can't figure it out.

so, now we will have to either just wait until Azoth matures or replace it with Pidgin or something. for me it seems that Azoth has good direction and i really would like to see its potential realized. so, what do you think is better for now: 1) use custom build with -DENABLE_MEDIACALLS=True 2) use Pidgin until Azoth stabilizes (empathy is not an options because of dependencies, kde-telepathy is too raw and full of KDE bullshit, other clients are barely alive or not functional enought) 3) give Azoth time and don't touch anything here, since no one really asking for that now anyway ?

[DAP-DarkneSS]

Check if Jingle could be used via Pidgin and Azoth with MEDIACALLS
enabled. I failed to do it because of provider's NAT or smth else I don't
really know. You could also check tox project.

[v-fox]

ok. could you, please, elaborate on (from that changelog): Sat Apr 5 11:56:18 UTC 2014 - dap.darkness@gmail.com

• 0.6.65 release: ...
• Shellopen plugin amd mediacalls became obsoleted.

obsoleted by what ? are they abandoned ? GStreamer transition is already going on and development for QtM-based ones stopped ? what happened ?

Tox looks like interesting project, definitely worth inclusion. It requires Qt5 though... But we still need xmpp jingle support too.

[0xd34df00d]

whole QtMultimedia seems like major pain in the ass

True.

so, now we will have to either just wait until Azoth matures or replace it with Pidgin or something. for me it seems that Azoth has good direction and i really would like to see its potential realized.

Thanks :) Anyway, moving to gstreamer is in my todo list, though quite far away in the queue. This'd tune the priority up, so I would vote for keeping Azoth as-is for now.

I'll comment here more as soon as I'd have some interesting results with gstreamer.

[0xd34df00d]

Also, regarding your questions on the changelog: I would rather say that "obsoleted" is a wrong word for "mediacalls", "experimental" or "unsupported" are rather better used IMO.

Shellopen is completely different story though, it's unrelated to Azoth or Jingle and is obsoleted by the newer functionality of the AdvancedNotifications module.

Also, FYI there is a Google echobot that can be used to test Jingle: echo@bot.talk.google.com

[v-fox]

Thanks :) Anyway, moving to gstreamer is in my todo list, though quite far away in the queue. This'd tune the priority up, so I would vote for keeping Azoth as-is for now. I'll comment here more as soon as I'd have some interesting results with gstreamer.

Thank you. I will.

Also, regarding your questions on the changelog: I would rather say that "obsoleted" is a wrong word for "mediacalls", "experimental" or "unsupported" are rather better used IMO.

It's quite disconcerting that such important feature would be unsupported and unprioritized :( And that's true for pretty much all XMPP projects, unfortunately. Not only are they hustle to configure to work via NAT (which now a double NAT in fucking Rostelecom, with two sets of internal IPs - 10./8 and 192.168./16... yeah) but functionality is not even there or well made.

Anyway, i modified DAP-DarkneSS 's spec and it looks like azoth-xoox has linked to QtMultimedia, but i still can't see any controls to initiate calls. How do they look like anyway ? _ On a side note, i made build for Tox and its GUIs which are quite messy and also found libpurple plugin for it, so even leechcraft should have at least textual support with it installed.

[0xd34df00d]

It's quite disconcerting that such important feature would be unsupported and unprioritized :(

Well, TBH the belief that Jingle is not actually needed is quite widespread as far as I can judge. At least when I asked for Jingle echobots today I got the reply that why bother with Jingle when there is SIP.

Another reason is that even if Jingle works, the negotiation could fail often due to different codecs, supported bitrates and so on.

Anyway, i modified DAP-DarkneSS 's spec and it looks like azoth-xoox has linked to QtMultimedia

You'd better check azoth core module as it's responsible for interaction with QtMultimedia, not azoth-xoox.

Also, I've pushed today a couple of commits that make Azoth link with QtMultimediaKit from QtMobility instead of plain QtMultimedia. Seems like it's just better supported (and the issue you linked previously proves this). See also this thread: https://groups.google.com/forum/#!topic/leechcraft/Ys-nj-20HT4

@DAP-DarkneSS is going to backport them to the 0.6.65 release if I got him right.

but i still can't see any controls to initiate calls. How do they look like anyway ?

It's a phone button icon, typically fifth from the left in the chat tab toolbar. Green one on the screenshot.

[v-fox]

Well, TBH the belief that Jingle is not actually needed is quite widespread as far as I can judge.

and how could it if still there is almost no xmpp clients with its complete and proper support ? looks like it will be a while until we can have full-blown F/OSS Skype analogue.

Another reason is that even if Jingle works, the negotiation could fail often due to different codecs, supported bitrates and so on.

i've noticed mentions of that. looks like the very standard of Jingle is half-assedly written.

You'd better check azoth core module It's a phone button icon

it's linked with QtMultimedia too, but icon is absent :(

Also, I've pushed today a couple of commits that make Azoth link with QtMultimediaKit from QtMobility instead of plain QtMultimedia. Seems like it's just better supported (and the issue you linked previously proves this)

heh, i hope it will make more good to Azoth than it did to PPSSPP, because despite those changes it still unusable for me due to unbearable speaker farting. works fine on Windows version though, but i suspect that Qt isn't used for audio there at all.

[0xd34df00d]

and how could it if still there is almost no xmpp clients with its complete and proper support ?

Yep, makes sense.

i've noticed mentions of that. looks like the very standard of Jingle is half-assedly written.

Just like some other XEPs :) Actually the biggest problem IMO is the standard optimistically relying on two clients always having some kind of common fallback and not enforcing them. But even if it enforced it, how would it guarantee that the clients obey?

it's linked with QtMultimedia too, but icon is absent :(

Hm, probably ENABLE_MEDIACALLS gets somehow mispassed. Let's wait for @DAP-DarkneSS builds.

heh, i hope it will make more good to Azoth than it did to PPSSPP, because despite those changes it still unusable for me due to unbearable speaker farting

Let's test :) Anyway, the nature of VoIP sound is slightly more forgiving to various glitches in sound than one of an emulator.

[v-fox]

Just like some other XEPs :) Actually the biggest problem IMO is the standard optimistically relying on two clients always having some kind of common fallback and not enforcing them. But even if it enforced it, how would it guarantee that the clients obey?

Indeed. Just shows that writing bunch of nice papers where everything is optional is not very practical, they at least should have made OpenGL approach in defining feature sets for protocol versions. and even with OpenGL, Mesa have made their own compliance testing framework just to not suck by accident and some people were wining for ages about there not being étalon/reference implementation from Khronos. So, reference client (well, and server) implementations at least made under guidance, if not by their hand, of whoever standardized XMPP protocol and extensions would have helped.

Hm, probably ENABLE_MEDIACALLS gets somehow mispassed. Let's wait for @DAP-DarkneSS builds

Ok, he knows better what's up... huh, it just rebuild itself once more on OBS and it's magically there ! Weird. Maybe i installed it yesterday too soon and damn thing managed to build packages for unmodified version and hang up on replacing them with new builds, as it does sometimes :| And looks like Google Bot is no much help, there is only farting from him with both LeechCraft and Psi+. It's maybe PulseAudio BS again, of course.

Anyway, the nature of VoIP sound is slightly more forgiving to various glitches in sound than one of an emulator.

Probably. But i blame PPSSPP's devs, because those are not just glitches, whole output is garbled, and there is something completely broken with bufferization. I think they don't even test Linux builds. So, unless you do the same thing, it should be fine.

[v-fox]

hm, something weird going on my system: first, both LC and Psi+ tried to capture from "Line In" (hence the "farting" from unconfigured TV tuner on "line in") although "Front Mic" was in priority and correctly shown in kmix and pavucontrol, even audacity either wasn't getting any capture data or stuck with "Line In". and then i have managed to make ALSA->JACK->Pulse-JACKsink setup and capturing started to work pretty damn good everywhere, including Psi+... but except LC :(

it really insists on getting direct ALSA access with:

ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave

looks like porting to GStreamer is really a way to go. not only it more stable and feature-rich but also flexible and works directly with JACK and a ton of other backends.

[0xd34df00d]

looks like porting to GStreamer is really a way to go. not only it more stable and feature-rich but also flexible and works directly with JACK and a ton of other backends

Well, QtMultimediaKit from QtMobility uses the GStreamer backend internally. The only thing stopping from using it on openSUSE is that QtMobility is built with gstreamer 0.10, while the rest of Qt stuff in openSUSE is built with gstreamer 1.0. I'll try patching QtMobility to support GStreamer 1.0 soon when I'll have some time for it.

[v-fox]

Damn, i just made the ultimate sound config: the first audio device is accessible directly with JACK and indirectly with PA-JACKSink simultaneously, all others, like HDMI, PCI & USB ones, etc. - directly with PA ! Everything works great... except maybe that PA still manages to mess with Mic's sensitivity, but it always does it. Of course, i integrated all that into HSF for the next release.

The only thing stopping from using it on openSUSE is that QtMobility is built with gstreamer 0.10, while the rest of Qt stuff in openSUSE is built with gstreamer 1.0.

Hm, but isn't that openSUSE doesn't have QtMobility in official reps at all ? In fact, the only Qt thing i see that links with gstreamer is libQtGStreamer-0_10 / gstreamer-0_10-plugins-qt. Moreover, that page says that GS1.0 support isn't done yet at all, not in Qt 4.x anyway.

And all those LC's errors about direct ALSA access and its absence from PA's application/client list makes me think that LC doesn't support PA output. How does Azoth finds & accesses its audio devices anyway ?

[0xd34df00d]

Damn, i just made the ultimate sound config: the first audio device is accessible directly with JACK and indirectly with PA-JACKSink simultaneously, all others, like HDMI, PCI & USB ones, etc. - directly with PA ! Everything works great... except maybe that PA still manages to mess with Mic's sensitivity, but it always does it.

Great! Though I never had any of these on my systems and had no such problems :) Though running proprietary apps relying on PA becomes somewhat hard.

Hm, but isn't that openSUSE doesn't have QtMobility in official reps at all ?

True, it doesn't. The primary reason for this is the mentioned conflict between gstreamer 0.10 (in QtMobility) and 1.0 (in suse). QtMobility is available for 13.1 in KDE repos though.

Moreover, that page says that GS1.0 support isn't done yet at all, not in Qt 4.x anyway.

That's why it would require some patching. The amount of code to be changed is likely to be quite small though, judging from my experience with supporting both 0.10 and 1.0 gstreamer in LMP.

And all those LC's errors about direct ALSA access and its absence from PA's application/client list makes me think that LC doesn't support PA output. How does Azoth finds & accesses its audio devices anyway ?

Via QtMultimedia, very likely direct ALSA querying internally.

[DAP-DarkneSS]

Hm, but isn't that openSUSE doesn't have QtMobility in official reps at
all

No problems to push it to Factory except gst 0.10 only support.

? Moreover, that page says
that GS1.0 support isn't done yet at all, not in Qt 4.x anyway.

Qt and other stuff was planned to patched to gst 1.0 for oS 13.1 but for
some reason It will be only for oS 13.2 aka Factory now.

[v-fox]

The primary reason for this is the mentioned conflict between gstreamer 0.10 (in QtMobility) and 1.0 (in suse)

I still don't understand what conflict is that, since i didn't see any Qt lib linked with GS1.0.

That's why it would require some patching. The amount of code to be changed is likely to be quite small though, judging from my experience with supporting both 0.10 and 1.0 gstreamer in LMP. Qt and other stuff was planned to patched to gst 1.0 for oS 13.1 but for some reason It will be only for oS 13.2 aka Factory now.

Well, that's quite an undertaking, since Qt guys were postponing that for years and, judging by the changelog, GS1.0 support is not even in 5.3, while they are too busy doing stuff for Windows and mobiles.

Via QtMultimedia, very likely direct ALSA querying internally.

:( Now that's worrying. Direct ALSA querying is really not an option nowadays, it's will mess up with all other apps. Why the hell Qt libs not using their Phonon crap or something ? Anyway, i would say that's the real problem, if calls are unreliable, glitchy or something - that's bearable, but if it tries to take over whole sound system - that's no way to go.

[0xd34df00d]

I still don't understand what conflict is that, since i didn't see any Qt lib linked with GS1.0.

QtWebkit is, for example, in Factory.

Well, that's quite an undertaking, since Qt guys were postponing that for years and, judging by the changelog, GS1.0 support is not even in 5.3, while they are too busy doing stuff for Windows and mobiles.

Manual patching of QtMultimediaKit is OK IMO.

:( Now that's worrying. Direct ALSA querying is really no way to go nowadays, it's will mess up with all other apps.

True.

Why the hell they not using their Phonon crap or something ?

Qt's Phonon doesn't allow capturing the sound anyway, thus somewhat unusable for VoIP. Also, Phonon is quite glitchy by itself — I fixed a few gstreamer-related issues merely by moving to direct gstreamer calling in the LMP player, but that's another story.

Anyway, i would say that's the real problem, if calls are unreliable, glitchy or something - that's bearable, but if it tries to take over whole sound system - that's no way to go.

QtMultimediaKit doesn't.

[DAP-DarkneSS]

I still don't understand what conflict is that, since i didn't see any
Qt lib linked with GS1.0.

http://en.opensuse.org/openSUSE:Goals_13.1/Port_to_GStreamer_1.0 https://build.opensuse.org/package/binary/openSUSE:Factory/libQtWebKit4?arch=x86_64&filename=libQtWebKit4-4.8.6%2B2.3.3-1.1.x86_64.rpm&repository=standard

[v-fox]

Phonon is quite glitchy by itself

Yeah, i finally got my hands on long awaited update for goldendict, the best dictionary software ever, in which the author replaced non-functional phonon pronunciation backend with direct libffmpeg usage. I bet he had enough of that also.

http://en.opensuse.org/openSUSE:Goals_13.1/Port_to_GStreamer_1.0

I've seen it, and it's a serious list. One has to be a really badass dude to do what Qt upstream wouldn't.

[v-fox]

Success ! Leechcraft from git indeed is able to use PA, even if it's with help of fat qt-mobility. I will use its snapshots for now, until working release. It looks like, however, that it forces input audio streams to be mono, even if they come from stereo microphone (like mine is, for some reason). Not critical since there is not much practical use for it, and output is mostly the same for both channels. Does Jingle even support stereo transmission ? Also, sound from Google echo bot disappears after a while. Not sure if that's bot's, azoth's or PA's issue.

Also, how good Azoth is with UPNP and STUN ? How about using UPNP for automatic Jingle port forwarding and setting default public stun server (like stun.ekiga.net) for zero user configuration ?

[0xd34df00d]

Success ! Leechcraft from git indeed is able to use PA, even if it's with help of fat qt-mobility.

Well, actually the whole qt-mobility library is not required, just the multimedia part of it.

I will use its snapshots for now, until working release.

BTW I'm thinking of a release in the next few days. I previously thought of waiting for a QTermWidget release (a new terminal emulator plugin has emerged in the meantime), but seems like we'll have to do without it for now.

It looks like, however, that it forces input audio streams to be mono, even if they come from stereo microphone (like mine is, for some reason). Not critical since there is not much practical use for it, and output is mostly the same for both channels. Does Jingle even support stereo transmission ?

Skimming through the specs makes me think that it should be supported if both parties support such encoding.

Also, sound from Google echo bot disappears after a while. Not sure if that's bot's, azoth's or PA's issue.

Hm, what's a typical time frame for this? I've played aroudn with Google echo bot only for a couple of minutes probably.

Also, how good Azoth is with UPNP and STUN ? How about using UPNP for automatic Jingle port forwarding and setting default public stun server (like stun.ekiga.net) for zero user configuration ?

UPNP isn't supported I guess (but it could be), and STUN should work. It requires either the user's XMPP server reporting the STUN server (in which case it'd be set up automatically), or manual configuration of a STUN proxy in account settings.

[v-fox]

Well, actually the whole qt-mobility library is not required, just the multimedia part of it.

For that it will have to be split into multiple packages, which i don't know if even worth it. But i'll do it. The sooner everyone can get rid of QtMultimedia.so.4, Kit or no Kit, the better.

Hm, what's a typical time frame for this? I've played aroudn with Google echo bot only for a couple of minutes probably.

I too. Was testing in-PA echo cancellation (which sucks, like the rest of it), and after just about few minutes it went silent. Seems to work better today. Let's blame PA for that, it done some other weird shit recently. PA echo cancellation for PA JACK client will be enabled by default in the next release too, by the way, which i was planning on doing these next few days too. Looks like waiting for your next release will be a good decision.

UPNP isn't supported I guess (but it could be), and STUN should work.

In the times of Double NAT and totalitarian communication control it should. UPNP is absolute must-have feature for networking client apps until IPv6's domination, which i'm not sure if will ever happen.

It requires either the user's XMPP server reporting the STUN server (in which case it'd be set up automatically), or manual configuration of a STUN proxy in account settings.

How ubiquitous are XMPP servers that provide STUN address ? I really doubt that even popular ones do. I think people would appreciate something that would allow launching Azoth and always having some working default, even when server doesn't provide it, like maybe global LC setting for default STUN that is inserted for all accounts unless overridden individually.

[v-fox]

Uh, 0.6.70 release's build for openSUSE isn't be having mediacalls enabled too ?(

[0xd34df00d]

I don't see any reason against enabling them, if QtMobility/QtMultimediaKit is available there. I'll ask Darkness about that.

Also, FYI I'm in the process of adding support for Qt5, and things should be even better there with multimedia support. I haven't tested Jingle yet, but other than that Azoth already starts and works fine (up to few Qt5-specific crashes).

[v-fox]

Great. I decided to wait for LXQt 0.8 release for now anyway (which should be "soon"), since changes are pretty hefty, may as well make a major update to DE.

On a side note: openSUSE starting to piss me off with its anti-ffmpeg and rpm bullshit... again. We, old Gentoo nerds, really should virtually get together some day and make 'Hardened Gentoo'-based enterprise-level binary distribution with yearly release cycle (where overlays are analogues of CentOS's SIGs) for Mother Russia's sake. It will be more straightforward, updated and secure than anything. And then do commercial integration and adoption for it. Just throwing that idea out for now.