used as template to compile silk into asterisk on Dockstar Arm device #2

Closed
yuyuyak opened this Issue May 4, 2013 · 8 comments

Comments

Projects
None yet
2 participants
@yuyuyak

yuyuyak commented May 4, 2013

Hi. Thanks very much for this. You did a lot of work and it shows. I saw your web page as I was working on it.
As the subject states I was instead going for an Arm install, same issue, x86, 64 binaries are no good here. Your install was close enough that I was able to modify it to work and it seems to work well. Can't test very thoroughly yet because the two devices I have to connect with asterisk have unrelated problems with Silk (sigh). But we'll get that fixed.
Two things took me some time to overcome (not counting all the "ghosts" I chased).
First, again, unrelated to your work, the Arm Silk distribution did NOT work for me. Spent many hours trying to compile it, it always lunched in the linking phase. The workaround was to use the FIXED version. It compiled perfectly without issue. BTW, it was all done native on the Armv5te device, no cross-compiling.
The second was a problem with install_silk.sh. Not that you did anything wrong, but when it added the lines to .../codecs/Makefile it added the command line (4th line) like this:
\t@$(MAKE) -C silk clean all
instead of
(REAL tab goes here)@$(MAKE) -C silk clean all
But that was pretty easy to track down from the error messages.
No complaints here. After I test it some more and get my thoughts organized I'd like to post the Arm version on my github if you don't mind. Of course, I will give you full credit.
My next step is to take your template and give Opus a try ;)
Thanks!

@mordak

This comment has been minimized.

Show comment
Hide comment
@mordak

mordak May 4, 2013

Owner

Hey!
I am really glad to hear that this was useful to you, and am interested to hear about how the rest of the install goes for you once you get things sorted out.
Kind of weird that the ARM build of the SILK_SDK didn't work for you, but it's good that the FIX version appears to have worked. The Skype folks may be interested to hear about your problems / findings.
As for the \t vs (REAL tab) thing, I bet that it's a shellism related to my using single quotes in the echo line. This works fine for my sh, but may not work for the shell you're using on the Dockstar. If you can patch install_silk.sh to work on your board then I will happy take a pull request on it.
As for posting your port, by all means please do. I am happy to point to your repo from mine, and if possible, we could try for a single version.
Cheers!

Owner

mordak commented May 4, 2013

Hey!
I am really glad to hear that this was useful to you, and am interested to hear about how the rest of the install goes for you once you get things sorted out.
Kind of weird that the ARM build of the SILK_SDK didn't work for you, but it's good that the FIX version appears to have worked. The Skype folks may be interested to hear about your problems / findings.
As for the \t vs (REAL tab) thing, I bet that it's a shellism related to my using single quotes in the echo line. This works fine for my sh, but may not work for the shell you're using on the Dockstar. If you can patch install_silk.sh to work on your board then I will happy take a pull request on it.
As for posting your port, by all means please do. I am happy to point to your repo from mine, and if possible, we could try for a single version.
Cheers!

@yuyuyak

This comment has been minimized.

Show comment
Hide comment
@yuyuyak

yuyuyak May 4, 2013

I have been testing it this morning, got Linphone Silk codec working fine now, and it seems excellent. Haven't had the opportunity to test in real life yet, in a few days perhaps. But calling the built-in echo test in Asterisk and even calling my Ulaw capable only Android just ... works. Asterisk clearly shows Silk12 being used and it works fine.
I think perhaps the Arm SDK is for Armv6-7, that seems common, they have no pity for users like me that buy old $15 Androids on Ebay. But who cares, the workaround is fine. Actually I stumbled upon a posting where another fellow had the same problem, that's when the light went on and I thought "why not try one of the others?" I doubt there will be much interest with the Silk developers as Opus is now overshadowing everything. And the posting was at their site.
Certainly it is a shell thing. I'll fool with that & see if I can find a happy medium. I did use sh (this is ArchArmLinux on the dockstar).
Great, we can make this more accessible for all. I think you are right, single version is best, after all, the only real change needed from platform to platform is the line in install_silk.sh that links the proper SDK. Perhaps a question pops up asking which you would like to use? Or just an instruction to change that line would perhaps be enough. In any case, I see no way around for future installers to 1st attempt compiling of the SDK's to see which works for them, independent of the Asterisk compile. If they are using anything other than MacOS or Armv5te that is.

yuyuyak commented May 4, 2013

I have been testing it this morning, got Linphone Silk codec working fine now, and it seems excellent. Haven't had the opportunity to test in real life yet, in a few days perhaps. But calling the built-in echo test in Asterisk and even calling my Ulaw capable only Android just ... works. Asterisk clearly shows Silk12 being used and it works fine.
I think perhaps the Arm SDK is for Armv6-7, that seems common, they have no pity for users like me that buy old $15 Androids on Ebay. But who cares, the workaround is fine. Actually I stumbled upon a posting where another fellow had the same problem, that's when the light went on and I thought "why not try one of the others?" I doubt there will be much interest with the Silk developers as Opus is now overshadowing everything. And the posting was at their site.
Certainly it is a shell thing. I'll fool with that & see if I can find a happy medium. I did use sh (this is ArchArmLinux on the dockstar).
Great, we can make this more accessible for all. I think you are right, single version is best, after all, the only real change needed from platform to platform is the line in install_silk.sh that links the proper SDK. Perhaps a question pops up asking which you would like to use? Or just an instruction to change that line would perhaps be enough. In any case, I see no way around for future installers to 1st attempt compiling of the SDK's to see which works for them, independent of the Asterisk compile. If they are using anything other than MacOS or Armv5te that is.

@mordak

This comment has been minimized.

Show comment
Hide comment
@mordak

mordak May 5, 2013

Owner

That's great that things are coming along, and I am glad that the codec appears to be just working. Keep plugging away. :-)

As for the install option, I am happy either way. Doing a select / menu is ideal but, as you say, may not be 100% accurate. The easy option is to do a uname -m and then switch based on the output with defined options for platforms we know something about, and defaulting to FIX otherwise (which, for our two known platforms, would mean always using FIX). Or we can just update the docs - I am not fussed either way. As you say, there will be some amount of trial and error for new platforms anyway. I am inclined to just updating the docs, since both of our cases use FIX for the moment.

Owner

mordak commented May 5, 2013

That's great that things are coming along, and I am glad that the codec appears to be just working. Keep plugging away. :-)

As for the install option, I am happy either way. Doing a select / menu is ideal but, as you say, may not be 100% accurate. The easy option is to do a uname -m and then switch based on the output with defined options for platforms we know something about, and defaulting to FIX otherwise (which, for our two known platforms, would mean always using FIX). Or we can just update the docs - I am not fussed either way. As you say, there will be some amount of trial and error for new platforms anyway. I am inclined to just updating the docs, since both of our cases use FIX for the moment.

@yuyuyak

This comment has been minimized.

Show comment
Hide comment
@yuyuyak

yuyuyak May 8, 2013

Hi. Just letting you know I haven't forgotten about this. I was
side-tracked with a "rescue my system" thing the last few days.
I agree with you, just doc update seems the best, as you say, trial and
error seems unavoidable. I am still having troubles here with
mediastreamer-silk for linphone, the gentoo install available is silk 1.0.8
and there are problems with it, see
https://bugs.gentoo.org/show_bug.cgi?id=445476
I'm the last poster there, Mike Johnson. I was mistaken when I said it
seemed to work fine otherwise, it causes linphone to lock up and other
problems too. So I may try & tackle updating the Gentoo install to the
1.0.9, see what happens. So anyhow, I can't really say how asterisk-silk
is going yet.
Cheers,
Mike

On Sun, May 5, 2013 at 6:19 AM, mordak notifications@github.com wrote:

That's great that things are coming along, and I am glad that the codec
appears to be just working. Keep plugging away. :-)

As for the install option, I am happy either way. Doing a select / menu is
ideal but, as you say, may not be 100% accurate. The easy option is to do a uname
-m and then switch based on the output with defined options for platforms
we know something about, and defaulting to FIX otherwise (which, for our
two known platforms, would mean always using FIX). Or we can just update
the docs - I am not fussed either way. As you say, there will be some
amount of trial and error for new platforms anyway. I am inclined to just
updating the docs, since both of our cases use FIX for the moment.


Reply to this email directly or view it on GitHubhttps://github.com/mordak/codec_silk/issues/2#issuecomment-17451613
.

yuyuyak commented May 8, 2013

Hi. Just letting you know I haven't forgotten about this. I was
side-tracked with a "rescue my system" thing the last few days.
I agree with you, just doc update seems the best, as you say, trial and
error seems unavoidable. I am still having troubles here with
mediastreamer-silk for linphone, the gentoo install available is silk 1.0.8
and there are problems with it, see
https://bugs.gentoo.org/show_bug.cgi?id=445476
I'm the last poster there, Mike Johnson. I was mistaken when I said it
seemed to work fine otherwise, it causes linphone to lock up and other
problems too. So I may try & tackle updating the Gentoo install to the
1.0.9, see what happens. So anyhow, I can't really say how asterisk-silk
is going yet.
Cheers,
Mike

On Sun, May 5, 2013 at 6:19 AM, mordak notifications@github.com wrote:

That's great that things are coming along, and I am glad that the codec
appears to be just working. Keep plugging away. :-)

As for the install option, I am happy either way. Doing a select / menu is
ideal but, as you say, may not be 100% accurate. The easy option is to do a uname
-m and then switch based on the output with defined options for platforms
we know something about, and defaulting to FIX otherwise (which, for our
two known platforms, would mean always using FIX). Or we can just update
the docs - I am not fussed either way. As you say, there will be some
amount of trial and error for new platforms anyway. I am inclined to just
updating the docs, since both of our cases use FIX for the moment.


Reply to this email directly or view it on GitHubhttps://github.com/mordak/codec_silk/issues/2#issuecomment-17451613
.

@yuyuyak

This comment has been minimized.

Show comment
Hide comment
@yuyuyak

yuyuyak May 9, 2013

Hello.
I am testing again today. I feel a bit foolish about that Gentoo bug,
original post is 5 months old and obviously there won't be any developer
response. And that is because if you follow through some older bug reports
there is a patch to solve the problem posted. So I've applied that patch
and it did solve that problem.
What I am finding is that Silk seems to work ok until either I use the
pause(hold) button in Linphone or the call is ended at either end. Then
Linphone hangs and must be killed & restarted. What I do not know is if
this is caused by the mediastreamer-silk codec or the asterisk silk codec.
I will peruse through comparing some other codec .c files and see what I
can see. My Introductory Borland C class 101 35 years ago doesn't much
qualify me, but I'll give it a shot.
I will say from the asterisk messages it does seem to be isolated to
Linphone, everything looks as it should on the asterisk cli. So I'm
leaning toward the mediastreamer-silk codec being faulty. Unfortunately
that is my #1 reason for all this, so I will do my best to solve it. My
android fairs even worse with silk, so it's worthless to test with it.
Mike

On Wed, May 8, 2013 at 2:29 PM, Yuyu Yakubu yuyuyak@gmail.com wrote:

Hi. Just letting you know I haven't forgotten about this. I was
side-tracked with a "rescue my system" thing the last few days.
I agree with you, just doc update seems the best, as you say, trial and
error seems unavoidable. I am still having troubles here with
mediastreamer-silk for linphone, the gentoo install available is silk 1.0.8
and there are problems with it, see
https://bugs.gentoo.org/show_bug.cgi?id=445476
I'm the last poster there, Mike Johnson. I was mistaken when I said it
seemed to work fine otherwise, it causes linphone to lock up and other
problems too. So I may try & tackle updating the Gentoo install to the
1.0.9, see what happens. So anyhow, I can't really say how asterisk-silk
is going yet.
Cheers,
Mike

On Sun, May 5, 2013 at 6:19 AM, mordak notifications@github.com wrote:

That's great that things are coming along, and I am glad that the codec
appears to be just working. Keep plugging away. :-)

As for the install option, I am happy either way. Doing a select / menu
is ideal but, as you say, may not be 100% accurate. The easy option is to
do a uname -m and then switch based on the output with defined options
for platforms we know something about, and defaulting to FIX otherwise
(which, for our two known platforms, would mean always using FIX). Or we
can just update the docs - I am not fussed either way. As you say, there
will be some amount of trial and error for new platforms anyway. I am
inclined to just updating the docs, since both of our cases use FIX for the
moment.


Reply to this email directly or view it on GitHubhttps://github.com/mordak/codec_silk/issues/2#issuecomment-17451613
.

yuyuyak commented May 9, 2013

Hello.
I am testing again today. I feel a bit foolish about that Gentoo bug,
original post is 5 months old and obviously there won't be any developer
response. And that is because if you follow through some older bug reports
there is a patch to solve the problem posted. So I've applied that patch
and it did solve that problem.
What I am finding is that Silk seems to work ok until either I use the
pause(hold) button in Linphone or the call is ended at either end. Then
Linphone hangs and must be killed & restarted. What I do not know is if
this is caused by the mediastreamer-silk codec or the asterisk silk codec.
I will peruse through comparing some other codec .c files and see what I
can see. My Introductory Borland C class 101 35 years ago doesn't much
qualify me, but I'll give it a shot.
I will say from the asterisk messages it does seem to be isolated to
Linphone, everything looks as it should on the asterisk cli. So I'm
leaning toward the mediastreamer-silk codec being faulty. Unfortunately
that is my #1 reason for all this, so I will do my best to solve it. My
android fairs even worse with silk, so it's worthless to test with it.
Mike

On Wed, May 8, 2013 at 2:29 PM, Yuyu Yakubu yuyuyak@gmail.com wrote:

Hi. Just letting you know I haven't forgotten about this. I was
side-tracked with a "rescue my system" thing the last few days.
I agree with you, just doc update seems the best, as you say, trial and
error seems unavoidable. I am still having troubles here with
mediastreamer-silk for linphone, the gentoo install available is silk 1.0.8
and there are problems with it, see
https://bugs.gentoo.org/show_bug.cgi?id=445476
I'm the last poster there, Mike Johnson. I was mistaken when I said it
seemed to work fine otherwise, it causes linphone to lock up and other
problems too. So I may try & tackle updating the Gentoo install to the
1.0.9, see what happens. So anyhow, I can't really say how asterisk-silk
is going yet.
Cheers,
Mike

On Sun, May 5, 2013 at 6:19 AM, mordak notifications@github.com wrote:

That's great that things are coming along, and I am glad that the codec
appears to be just working. Keep plugging away. :-)

As for the install option, I am happy either way. Doing a select / menu
is ideal but, as you say, may not be 100% accurate. The easy option is to
do a uname -m and then switch based on the output with defined options
for platforms we know something about, and defaulting to FIX otherwise
(which, for our two known platforms, would mean always using FIX). Or we
can just update the docs - I am not fussed either way. As you say, there
will be some amount of trial and error for new platforms anyway. I am
inclined to just updating the docs, since both of our cases use FIX for the
moment.


Reply to this email directly or view it on GitHubhttps://github.com/mordak/codec_silk/issues/2#issuecomment-17451613
.

@mordak

This comment has been minimized.

Show comment
Hide comment
@mordak

mordak May 9, 2013

Owner

Hmm.. Do you see the same problems with Linphone when you use other codecs? My experience with SIP is that issues with hangups or holding is usually something in the SIP stack, and not so much with the codec. Though if the app hangs it could be tied up waiting on the codec to do something that isn't going to happen. It may be useful to try a different client, if you can, and see if the behaviour persists. If you get the same problem across several clients, it would indicate something maybe on the asterisk end. It sounds like you are well into it though, so best of luck.

Owner

mordak commented May 9, 2013

Hmm.. Do you see the same problems with Linphone when you use other codecs? My experience with SIP is that issues with hangups or holding is usually something in the SIP stack, and not so much with the codec. Though if the app hangs it could be tied up waiting on the codec to do something that isn't going to happen. It may be useful to try a different client, if you can, and see if the behaviour persists. If you get the same problem across several clients, it would indicate something maybe on the asterisk end. It sounds like you are well into it though, so best of luck.

@yuyuyak

This comment has been minimized.

Show comment
Hide comment
@yuyuyak

yuyuyak May 11, 2013

Hello.
I am pleased to tell you that the hold/hangup problem is localized to
Linphone only. I have an old computer here with Gentoo on it, installed
Linphone and then connected the two Linphone clients peer to peer,
bypassing asterisk altogether. Still they freeze on hold/hangup. Only
with the Silk codec, no other codecs exhibit that symptom. So I shall deal
with that problem in time. I am amazed that there are no complaints from
the community, these are quite different computers, although they are both
Gentoo/Funtoo, so others MUST have the problem as well. I believe Linphone
is open source, so perhaps I can take a look at the source code. I thought
it might be due to some GTK+ problem but no, the command-line versions of
Linphone do it as well.
I've yet to find flaw with your implementation, even when I call the
Asterisk echo test, which plays back GSM encoded audio clips, the
translation seems to work fine, at least until it hangs up ;)
On the subject of echoing the tab reliably to a file, I think I have found
the answer. I searched and found this discussion on the web:
http://stackoverflow.com/questions/525872/echo-spaces-in-bash-script
One fellow in there mentions using printf for portability and indeed, it
works perfectly on my Arch-Arm installation in both sh and bash, and on my
Funtoo installation as well. If it does the same for MacOS, problem
solved. As in:
printf '\t@$(MAKE) -C silk clean all' >> Makefile
Thanks for your help.
Mike

On Thu, May 9, 2013 at 2:27 PM, mordak notifications@github.com wrote:

Hmm.. Do you see the same problems with Linphone when you use other
codecs? My experience with SIP is that issues with hangups or holding is
usually something in the SIP stack, and not so much with the codec. Though
if the app hangs it could be tied up waiting on the codec to do something
that isn't going to happen. It may be useful to try a different client, if
you can, and see if the behaviour persists. If you get the same problem
across several clients, it would indicate something maybe on the asterisk
end. It sounds like you are well into it though, so best of luck.


Reply to this email directly or view it on GitHubhttps://github.com/mordak/codec_silk/issues/2#issuecomment-17691020
.

yuyuyak commented May 11, 2013

Hello.
I am pleased to tell you that the hold/hangup problem is localized to
Linphone only. I have an old computer here with Gentoo on it, installed
Linphone and then connected the two Linphone clients peer to peer,
bypassing asterisk altogether. Still they freeze on hold/hangup. Only
with the Silk codec, no other codecs exhibit that symptom. So I shall deal
with that problem in time. I am amazed that there are no complaints from
the community, these are quite different computers, although they are both
Gentoo/Funtoo, so others MUST have the problem as well. I believe Linphone
is open source, so perhaps I can take a look at the source code. I thought
it might be due to some GTK+ problem but no, the command-line versions of
Linphone do it as well.
I've yet to find flaw with your implementation, even when I call the
Asterisk echo test, which plays back GSM encoded audio clips, the
translation seems to work fine, at least until it hangs up ;)
On the subject of echoing the tab reliably to a file, I think I have found
the answer. I searched and found this discussion on the web:
http://stackoverflow.com/questions/525872/echo-spaces-in-bash-script
One fellow in there mentions using printf for portability and indeed, it
works perfectly on my Arch-Arm installation in both sh and bash, and on my
Funtoo installation as well. If it does the same for MacOS, problem
solved. As in:
printf '\t@$(MAKE) -C silk clean all' >> Makefile
Thanks for your help.
Mike

On Thu, May 9, 2013 at 2:27 PM, mordak notifications@github.com wrote:

Hmm.. Do you see the same problems with Linphone when you use other
codecs? My experience with SIP is that issues with hangups or holding is
usually something in the SIP stack, and not so much with the codec. Though
if the app hangs it could be tied up waiting on the codec to do something
that isn't going to happen. It may be useful to try a different client, if
you can, and see if the behaviour persists. If you get the same problem
across several clients, it would indicate something maybe on the asterisk
end. It sounds like you are well into it though, so best of luck.


Reply to this email directly or view it on GitHubhttps://github.com/mordak/codec_silk/issues/2#issuecomment-17691020
.

@mordak

This comment has been minimized.

Show comment
Hide comment
@mordak

mordak May 12, 2013

Owner

printf works great here - I have updated the repo with that change. Thanks!

Good luck with the linphone silk codec. For sure other people have the same problem, as you say, but there's all kinds of reasons why it might not be patched. Weird that it's confined to the one codec, but if you start digging through source that may at least direct your efforts on where to look for differences between the silk codec and other codecs.

Cheers,
Todd

Owner

mordak commented May 12, 2013

printf works great here - I have updated the repo with that change. Thanks!

Good luck with the linphone silk codec. For sure other people have the same problem, as you say, but there's all kinds of reasons why it might not be patched. Weird that it's confined to the one codec, but if you start digging through source that may at least direct your efforts on where to look for differences between the silk codec and other codecs.

Cheers,
Todd

@mordak mordak closed this Aug 28, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment