Re: [maemo-developers] Unresolved issues (Week 46)
Pada hari Senin, tanggal 20/11/2006 pukul 15:28 +0200, ext Mohammad Anwari menulis: > Hi, > > Currently the file format is not published. Hi, Correcting my self. The file format is available in /usr/share/libimlayouts/fileformat.html in your maemo rootstrap. However, the API to use the file is not published. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
On Thursday 23 November 2006 22:19, Charles 'Buck' Krasic wrote: > No, my dsp work was actually video related.I did reuse Siarhei > Siamashka's mplayer code to decode/output mp3 directly, but that > obviously doesn't help with speex. Just a disclaimer before anybody starts bashing my ugly hack that allows to use dspmp3sink for mp3 playback from mplayer :) I know that it is improper use of gstreamer api for audio synchronization, but anything that looked somewhat better (proper buffer timestamps, the use of gstreamer pipeline clock instead of system time, ...) appeared to work even worse in my tests. So the code that is currently used in mplayer is bad, but the other options seemed to be even worse :( Surely it was not the best experience to start getting familiar with gstreamer and I'm surely not going to start looking for the one who is at fault here, there is a high probability that I missed something important and it is me after all ;) Anybody who can fix gstreamer based output module for mplayer is welcome to submit a patch. The only excuse for keeping this bad code in maemo build of mplayer is that it provides some performance improvement and works quite acceptable (audio/video sync is ok) most of the time. Now as the sources of gstreamer plugins are available, they may provide some insights about how to use them better and what could be wrong. > I'd suggest that the most practical approach for now would be to have > an application that uses a speex dsp task to decode speex, and then > takes the output from that speex task and routes it to an existing > gstreamer plugin for pcm output. This may be suboptimal, as the > data will cross the dsp gateway boundary twice more than necessary, > but it still might retain most of the benefit of offloading speex work > to the dsp.I mean were talking something like 64KB/s of extra > copying in the worst case (?), which I don't think will be a very > significant cost even on the 770's OMAP processor. > > The marginal benefit of persuing a zero copy solution (direct from dsp > to sound) just probably isn't work the effort. Documentation for the > software components of the 770 that use the dsp is virtually > non-existent until now. Aside from the mp3 decoder, I think all of > the other stuff has been basically unavailable to developers outside > of those working on Nokia's closed source multimedia applications. > On the bright side, the gstreamer plugins for these various pieces has > been made open source in maemo 2.1. I wouldn't hold my breath on > the dsp side of these plugins ever becoming open source (although I > would wholeheartedly welcome it!). It would be very nice to have the sources (maybe some stripped down version) of C55x stuff that is used by dsppcmsink as a template for implementing thirdparty dsp based decoders. But maybe I'm asking for too much :) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No, my dsp work was actually video related.I did reuse Siarhei Siamashka's mplayer code to decode/output mp3 directly, but that obviously doesn't help with speex. I'd suggest that the most practical approach for now would be to have an application that uses a speex dsp task to decode speex, and then takes the output from that speex task and routes it to an existing gstreamer plugin for pcm output. This may be suboptimal, as the data will cross the dsp gateway boundary twice more than necessary, but it still might retain most of the benefit of offloading speex work to the dsp.I mean were talking something like 64KB/s of extra copying in the worst case (?), which I don't think will be a very significant cost even on the 770's OMAP processor. The marginal benefit of persuing a zero copy solution (direct from dsp to sound) just probably isn't work the effort. Documentation for the software components of the 770 that use the dsp is virtually non-existent until now. Aside from the mp3 decoder, I think all of the other stuff has been basically unavailable to developers outside of those working on Nokia's closed source multimedia applications. On the bright side, the gstreamer plugins for these various pieces has been made open source in maemo 2.1. I wouldn't hold my breath on the dsp side of these plugins ever becoming open source (although I would wholeheartedly welcome it!). - -- Buck Simon Pickering wrote: > > >>> If you want something free, I'd suggest using our speex >> >> codec, which >> >>> is technically comparable, completely open, and has no known >>> patent issues. We don't have an omap dsp implementation, but it >>> has been ported to the various TI DSPs. >>> >>> http://speex.org/ >>> >>> -r >> >> I did quite a bit of experimentation with the 770 dsp back in >> late august. As a point of clarification, the dsp in the OMAP >> 1710 (used in the 770) is just a TI *C55x, *which is already >> supported by speex as far as I can tell. Thus, getting speex >> to work on the 770 should mostly be an issue of adapting the he >> exisiting speex C55x port to the build process using the free dsp >> tools, or TI's code composer; and writing appropriate wrappers to >> move data back and forth across the ARM to DSP boundary using the >> linux dsp gateway interfaces. >> > > There's still the problem of getting the DSP to output sound > directly though, is there not? Or did you work out what the > functions in the avs_kernel do (or bypass them completely)? > > > Simon > > ___ maemo-developers > mailing list maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFZgI8PrrWIMa4SMsRAtwtAKCewZZX7kvSYuXizfLAuKHcT840QACfb1p+ Ch8kmyDqxZveYbJbpPSfBC0= =ovMU -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Unresolved issues (Week 46)
> > > If you want something free, I'd suggest using our speex > codec, which > > is technically comparable, completely open, and has no known patent > > issues. We don't have an omap dsp implementation, but it has been > > ported to the various TI DSPs. > > > > http://speex.org/ > > > > -r > > I did quite a bit of experimentation with the 770 dsp back in late > august. As a point of clarification, the dsp in the OMAP 1710 (used > in the 770) is just a TI *C55x, *which is already supported by speex > as far as I can tell.Thus, getting speex to work on the 770 should > mostly be an issue of adapting the he exisiting speex C55x > port to the build process using the free dsp tools, or TI's > code composer; and writing appropriate wrappers to move data > back and forth across the > ARM to DSP boundary using the linux dsp gateway interfaces. > There's still the problem of getting the DSP to output sound directly though, is there not? Or did you work out what the functions in the avs_kernel do (or bypass them completely)? Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralph Giles wrote: > > If you want something free, I'd suggest using our speex codec, > which is technically comparable, completely open, and has no known > patent issues. We don't have an omap dsp implementation, but it has > been ported to the various TI DSPs. > > http://speex.org/ > > -r I did quite a bit of experimentation with the 770 dsp back in late august. As a point of clarification, the dsp in the OMAP 1710 (used in the 770) is just a TI *C55x, *which is already supported by speex as far as I can tell.Thus, getting speex to work on the 770 should mostly be an issue of adapting the he exisiting speex C55x port to the build process using the free dsp tools, or TI's code composer; and writing appropriate wrappers to move data back and forth across the ARM to DSP boundary using the linux dsp gateway interfaces. I'd be happy to try and help anyone who might be interested in attempting such an endeavor. - -- Buck > ___ maemo-developers > mailing list maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFZM5PPrrWIMa4SMsRAqMOAKCq0OqKRvgXwlR/Ws8FWm1ail2JbACfVLGN gxOIllBieMtH4goXOW4sfs4= =3yoS -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
On Wed, Nov 22, 2006 at 01:47:45PM -0600, Ed Okerson wrote: > The iLBC implementation on the DSP is closed source, but is bitstream > compatible with the one on ilbcfreeware.org. Since people seem confused: iLBC is a semi-proprietary voice codec. The design is documented as RFC 3951, and a reference implementation is available under their own license. As I understand the terms, you're free to use and hack the reference implementation for personal non- commercial use. Commercial use and distribution is allowed if the implementation is compatible with the published standard, and if you notify Global IP Sound (the authors) about it. As such, this license is incompatible with Free Software use. The license on the reference implementation covers both copyright and patent monopolies. Copyright can of course been worked around by doing a from-scratch implementation from the RFC. Global IP Sound has filed a pledge with the IETF to grant a royalty-free patent license to such (conforming) implementations. They don't says if the terms would be compatible with Free Software, so one would have to try and see. http://www.ietf.org/ietf/IPR/global-ip-ipr-draft-ietf-avt-ilbc-codec.txt http://www.ietf.org/ietf/IPR/GLOBAL-IP-ANDERSON.txt So, it cannot be extended without cooperation from the patent holders; a free software or open source implementation might or might not be possible depending on their interest. But as non-free software goes, it's not too bad. If you want something free, I'd suggest using our speex codec, which is technically comparable, completely open, and has no known patent issues. We don't have an omap dsp implementation, but it has been ported to the various TI DSPs. http://speex.org/ -r ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
> On Wed, 2006-11-22 at 15:40 +0200, Jari Tenhunen wrote: >> The .ilbc files contain simply raw iLBC frames (20 ms) one after >> another. Exactly the same stuff that dspilbcsrc produces and dspilbcsink >> eats. > > I google'd around, but the only pages mentionning dspilbcsrc or > audio/x-iLBC were maemo related. > > I tried browsing https://stage.maemo.org/viewcvs.cgi/maemo/ > but couldn't find sources for a coder/decoder for iLBC, any idea? The iLBC implementation on the DSP is closed source, but is bitstream compatible with the one on ilbcfreeware.org. Ed Okerson ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
On Wed, 2006-11-22 at 15:40 +0200, Jari Tenhunen wrote: > The .ilbc files contain simply raw iLBC frames (20 ms) one after > another. Exactly the same stuff that dspilbcsrc produces and dspilbcsink > eats. I google'd around, but the only pages mentionning dspilbcsrc or audio/x-iLBC were maemo related. I tried browsing https://stage.maemo.org/viewcvs.cgi/maemo/ but couldn't find sources for a coder/decoder for iLBC, any idea? Laurent ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
Here is a very small file (7KB): http://guerby.org/ftp/Test.ilbc Laurent PS: I made this file to ask Canonical (Ubuntu parent company) if they were able to read it, they answered no and had no knowledge of a debian package doing so. Is the code used on the Nokia 770 for ilbc open source? (I did not look around). On Wed, 2006-11-22 at 13:29 +0100, Panagiotis Issaris wrote: > Hi, > > On Wed, 2006-11-22 at 12:50 +0100, Laurent GUERBY wrote: > >... > > > > But it produces ".ilbc" files that I couldn't read anywhere > > except on my Nokia 770. A converter or direct output in > > a more readily available format would be great. > Would it be possible to put some samples publicly accessible? > > With friendly regards, > Takis > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
On Wed, Nov 22, 2006 at 01:29:09PM +0100, Panagiotis Issaris wrote: > Hi, > > On Wed, 2006-11-22 at 12:50 +0100, Laurent GUERBY wrote: > >... > > > > But it produces ".ilbc" files that I couldn't read anywhere > > except on my Nokia 770. A converter or direct output in > > a more readily available format would be great. > Would it be possible to put some samples publicly accessible? The .ilbc files contain simply raw iLBC frames (20 ms) one after another. Exactly the same stuff that dspilbcsrc produces and dspilbcsink eats. Yes, it would be best to use some container format but at least I'm not aware of any for iLBC. Regards, Jari T -- Jari Tenhunen, stardate [-29]6721.81 :wq ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
Hi, On Wed, 2006-11-22 at 12:50 +0100, Laurent GUERBY wrote: >... > > But it produces ".ilbc" files that I couldn't read anywhere > except on my Nokia 770. A converter or direct output in > a more readily available format would be great. Would it be possible to put some samples publicly accessible? With friendly regards, Takis -- vCard: http://www.issaris.org/pi.vcf Public key: http://www.issaris.org/pi.key ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
On Mon, 2006-11-20 at 15:13 +0200, Tommi Komulainen wrote: > Here is a list of issues raised on this list I think have not been > concluded so far, in no particular order. The easiest way to get off the > list is to provide answers, but you can also try convincing me other > ways. > > This is an attempt to improve our communication by providing a short > summary reminder for busy people to act on. I'll try to keep up with the > experiment for a few weeks and see what happens. Great! Something I mentionned a few times on this list is for people using their Nokia 770 as a sound recorder (I did and it works quite well without equipment): https://maemo.org/bugzilla/show_bug.cgi?id=717 Since the opening of this request, maemo recorder was developped (thanks to the authors :): https://garage.maemo.org/projects/maemo-recorder/ But it produces ".ilbc" files that I couldn't read anywhere except on my Nokia 770. A converter or direct output in a more readily available format would be great. Sincerely, Laurent http://guerby.org/blog/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
