[jitsi-dev] bugs


#1

1. This description of where to find the logs is wrong for OS X: https://jitsi.org/Documentation/FAQ#logs

Specifically, there is no "Tools->Options" menu item. Instead you go to "Jitsi->preferences", select advanced, and logs. FWIW, I would never think to go to preferences to get a copy of my logs. Tools, okay. Help okay. Not preferences.

2. This description says that logs are in "~/Library/Application Support/Jitsi" on the mac https://jitsi.org/Documentation/FAQ#jitsi-home

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 app.

3. I had some trouble with the input devices and had to restart Jitsi a few times to get it to pickup my mike. 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.

I wrote the original version of the current OS X implementation of PortAudio so I can probably help with this.

bjorn

···

-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
http://blog.bjornroche.com
@xonamiaudio


#2

Hey Bjorn,

1. This description of where to find the logs is wrong for OS X:
https://jitsi.org/Documentation/FAQ#logs

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.

2. This description says that logs are in "~/Library/Application
Support/Jitsi" on the mac
https://jitsi.org/Documentation/FAQ#jitsi-home

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
app.

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.

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?

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?

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?)

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 years).

Cheers,
Emil

···

On 24.07.13, 01:18, Bjorn Roche wrote:

--
https://jitsi.org


#3

Hey Bjorn,

1. This description of where to find the logs is wrong for OS X:
https://jitsi.org/Documentation/FAQ#logs

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
https://jitsi.org/Documentation/FAQ#jitsi-home

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
app.

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 recommended place:

http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/CoreDataUtilityTutorial/Articles/04_appSupport.html#//apple_ref/doc/uid/TP40001800-CH227-TP9

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.

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.

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.

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 years).

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.

  bjorn

···

On Jul 23, 2013, at 8:32 PM, Emil Ivov wrote:

On 24.07.13, 01:18, Bjorn Roche wrote:

-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
http://blog.bjornroche.com
@xonamiaudio


#4

-- sent from my mobile

Hey Bjorn,

1. This description of where to find the logs is wrong for OS X:
https://jitsi.org/Documentation/FAQ#logs

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
https://jitsi.org/Documentation/FAQ#jitsi-home

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
app.

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.

I haven't had the time to work on this yet, but given that this is not only a Windows problem (anymore) I'll try to get at this in a more generic way so that Macs, and possibly Linux (with /var/logs) can also benefit.

It is not well documented, but ~/Library/logs/Jitsi is the apple recommended place:

http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/CoreDataUtilityTutorial/Articles/04_appSupport.html#//apple_ref/doc/uid/TP40001800-CH227-TP9

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.

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.

Yes, you'd need to 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.

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 years).

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.

   bjorn

-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
http://blog.bjornroche.com
@

Ingo

···

Le 24.07.2013 à 04:47, "Bjorn Roche" <bjorn@xowave.com> a écrit :

On Jul 23, 2013, at 8:32 PM, Emil Ivov wrote:

On 24.07.13, 01:18, Bjorn Roche wrote:


#5

> Hey Bjorn,
>
>>
>>
>> 1. This description of where to find the logs is wrong for OS X:
>> https://jitsi.org/Documentation/FAQ#logs
>>
>> 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.

Great.

>> 2. This description says that logs are in "~/Library/Application
>> Support/Jitsi" on the mac
>> https://jitsi.org/Documentation/FAQ#jitsi-home
>>
>> 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
>> app.
>
> 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
recommended place:

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.

Thanks.

>> 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
years).

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).
(non-resolved)http://music.columbia.edu/pipermail/portaudio/2010-April/010214.html

Werner's patch for the ALSA problem
(non-merged):http://music.columbia.edu/pipermail/portaudio/2010-January/009760.html

Vincent's first mail on our hotplug patch
(non-merged):http://music.columbia.edu/pipermail/portaudio/2012-March/013608.html

The above meant that we needed to build our home-made fork on top of the
hotplug changes.

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
have.

Emil

···

On Jul 24, 2013 4:45 AM, "Bjorn Roche" <bjorn@xowave.com> wrote:

On Jul 23, 2013, at 8:32 PM, Emil Ivov wrote:
> On 24.07.13, 01:18, Bjorn Roche wrote:


#6

Sorry for the delay, some personal issues came up and I wasn't able to get to this. I at least created tickets:

>
>
>
> > Hey Bjorn,
> >
> >>
> >>
> >> 1. This description of where to find the logs is wrong for OS X:
> >> https://jitsi.org/Documentation/FAQ#logs
> >>
> >> 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.

Great.

ticket 1197

> >> 2. This description says that logs are in "~/Library/Application
> >> Support/Jitsi" on the mac
> >> https://jitsi.org/Documentation/FAQ#jitsi-home
> >>
> >> 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
> >> app.
> >
> > 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
> recommended place:
>
> 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.

Ticket 1195.

> >> 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.

Thanks.

> >> 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?
>

ticket 1196.

> Apparently I need some sort of login for Trac.

Ingo already answered: you can create one.

Sorry I missed this -- on the other trac system I've used you had to ask an admin.

> >> 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!

If you know off the top of your head where this code is I'll look at it. I'm sure it's simple.

We also reported a couple of issues on Linux:

Hanging capture (mails from Lyubomir, Werner and Damian). (non-resolved)
http://music.columbia.edu/pipermail/portaudio/2010-April/010214.html

Werner's patch for the ALSA problem (non-merged):
http://music.columbia.edu/pipermail/portaudio/2010-January/009760.html

A later post suggests that this was believed to have been fixed by a different PA codechange. Can you confirm that the problem still exists? If so, I will post a ticket for you.

Vincent's first mail on our hotplug patch (non-merged):
http://music.columbia.edu/pipermail/portaudio/2012-March/013608.html

Seems there were some unresolved issues. This is the last post on the thread: http://music.columbia.edu/pipermail/portaudio/2012-March/013625.html

  bjorn

···

On Jul 24, 2013, at 9:08 AM, Emil Ivov wrote:

On Jul 24, 2013 4:45 AM, "Bjorn Roche" <bjorn@xowave.com> wrote:
> On Jul 23, 2013, at 8:32 PM, Emil Ivov wrote:
> > On 24.07.13, 01:18, Bjorn Roche wrote:

-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
http://blog.bjornroche.com
@xonamiaudio