> Hey Bjorn,
>> 1. This description of where to find the logs is wrong for OS X:
>> Specifically, there is no "Tools->Options" menu item. Instead you go
>> to "Jitsi->preferences", select advanced, and logs.
> Fixed, thanks.
>> FWIW, I would
>> never think to go to preferences to get a copy of my logs. Tools,
>> okay. Help okay. Not preferences.
> Noted. A patch adding this to tools would be welcome.
Honestly, I find Jitsi code pretty hard to follow, but if I can figure it
out quickly, I will.
>> 2. This description says that logs are in "~/Library/Application
>> Support/Jitsi" on the mac
>> This is nonstandard. A better place for logs would be is
>> ~/Library/logs/Jitsi. One reason this would be a good change is it
>> would make it easier for folks who are used to using the console
> You have a point although it's not an extremely compelling
> argument. Jitsi is not unique in doing this (I have 10+ applications
> doing the same). It's just most convenient for us to have the
> directory within our profile.
> Ingo had a stronger case for changing this on windows where use
> of network devices for loading profiles is more common.
> Feel free to also open a ticket but given our current log of issues it
> might be a while before we get there.
It is not well documented, but ~/Library/logs/Jitsi is the apple
There are a number of reasons for this, particularly for admins. (eg,
admins know they can clean up ~/Library/logs and ~/Library/caches
without doing any harm. They know where they can find logs. They
can open Console and view logs for any compliant app, or daemon,
etc). Not every app is compliant, but that doesn't make it okay,
especially for an app like jitsi that produces a lot of logs.
What I was trying to say was: I understand that this is the convention.
However, the current situation is working ok for us. "Administrators will
be able to delete the logs at will" is not an argument that is compelling
enough to make this a priority.
"It causes Jitsi to crash" would have been one.
In view of that, if anyone is willing to work on it, then great! I have
nothing against the change itself.
>> 3. I had some trouble with the input devices and had to restart Jitsi
>> a few times to get it to pickup my mike.
> Weird. A bit too vague though. Do you have logs?
Yes, too vague. I'll be more specific if I play with it again.
>> Another thing I noticed was
>> that no matter how loud the input source was, the level meter never
>> went to the top, only like 90%, which is misleading.
> Point. Could you please open a ticket?
Apparently I need some sort of login for Trac.
Ingo already answered: you can create one.
>> I wrote the original version of the current OS X implementation of
>> PortAudio so I can probably help with this.
> That will be great! (I assume this was about the device issue?)
Maybe I can help with the metering issue as well, though that's
probably just a simple arithmetic error.
Cool! That would be most welcome!
> Note however that there is a chance that we would move a way from
PortAudio in the following month or two to a new default. (Still, if we do
that, PortAudio is likely to stay as an alternative for at least a few
Can I ask why? Are there missing features or bugs?
I don't recall any issues ever being brought up by the jitsi team on the
mailing list, though you may not have identified yourselves as such. I
don't maintain the mac code anymore, but I can still contribute, so if
there's a specific problem I may be able to help.
Various reasons. We've had to deal with a number of crashes and quality
issues on all OSes.
We've tried to deal with many of them and the changes are available here:
http://github.com/emcho/portaudio (or in our libsrc)
This has been quite a laborious process however and it has taken a lot of
effort. There are things in PortAudio, such as guaranteeing a
user-specified constant latency during read and right, that significantly
contribute to complexity. We don't need such features in Jitsi though, so
this only makes debugging harder without bringing anything.
We have already provided alternatives for Linux and Windows which are now
defaults there. In addition to the complexity mentioned above, this also
kind of kills the portability for us.
We have posted on the mailing list a few times. You actually commented on
one of our posts. You might remember the hotplug patch.
We also reported a couple of issues on Linux:
Hanging capture (mails from Lyubomir, Werner and Damian).
Werner's patch for the ALSA problem
Vincent's first mail on our hotplug patch
The above meant that we needed to build our home-made fork on top of the
Using such a fork is probably the biggest issue. It basically means that we
are on our own when it comes to maintaining it and if that's the case then
we'd rather lose the extra complexity that we don't need.
This is in no way criticism toward the PortAudio community. We will
continue doing so as a non-default audio system for quite a while as
mentioned above. We are immensely grateful to you and everyone else for all
the hard work: PortAudio has been a life saviour for us when we needed a
quick way of migrating away from Java Sound.
That said, being in the same position every so often, we perfectly
understand that our problems and requirements are not everyone else's. We
are not particularly excited at the prospect of rewriting an audio layer
... we are not masochists. It is simply the most feasible option that we
On Jul 24, 2013 4:45 AM, "Bjorn Roche" <firstname.lastname@example.org> wrote:
On Jul 23, 2013, at 8:32 PM, Emil Ivov wrote:
> On 24.07.13, 01:18, Bjorn Roche wrote: