drumkv1_0.3.3-1_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 30 Jun 2013 16:47:16 +0100 Source: drumkv1 Binary: drumkv1 Architecture: source amd64 Version: 0.3.3-1 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org Changed-By: Alessio Treglia ales...@debian.org Description: drumkv1- old-school drum-kit sampler Changes: drumkv1 (0.3.3-1) unstable; urgency=low . [ Jaromír Mikeš ] * Added myself as uploader . [ Alessio Treglia ] * New upstream release. Checksums-Sha1: 19cfde5e72b3da58210f55a7e9d7594eccd96c4b 2092 drumkv1_0.3.3-1.dsc df9944ab93c64bc7bf8e4429bd19e2ff649f 135246 drumkv1_0.3.3.orig.tar.gz 4d59a443780236b7a65c3320502f53b529cb7a9d 3021 drumkv1_0.3.3-1.debian.tar.gz 543caee5086b89efed36161c6af8563a478bbd15 256708 drumkv1_0.3.3-1_amd64.deb Checksums-Sha256: a7612d29f64668a0d6f892c2bd045c24c86361c53061edcbed50168eafb4d6ea 2092 drumkv1_0.3.3-1.dsc 554270e967eb6f36fdd37efd4b7773216fa6cf1a5027749012d16b239d7fbdf5 135246 drumkv1_0.3.3.orig.tar.gz fe74f013de8a9050abedc851af094e681bfdb201c330808f46e3f230cd076d92 3021 drumkv1_0.3.3-1.debian.tar.gz caedc79ac4a1d51ed51705c22a328fec322adba9e97787187618de491be7bc0a 256708 drumkv1_0.3.3-1_amd64.deb Files: a7cc09755d18d938120b51d074f4da19 2092 sound optional drumkv1_0.3.3-1.dsc d7c7270fdd01552b74eead36dd638ea4 135246 sound optional drumkv1_0.3.3.orig.tar.gz 29a1bf987c2b702a6f6c905483c171a4 3021 sound optional drumkv1_0.3.3-1.debian.tar.gz 9028bf6723675e27fd0139c893f10a09 256708 sound optional drumkv1_0.3.3-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJR0FVcAAoJEOikiuUxHXZaOGQP/0vLoF77DoReq9lMqOypAwy6 eW5DfyqfT3FVutNBZXLeWEcpipTGi0a/p7JoEj2Utgy+yLlt+tSoq/ZGb8DcGu1a Q3iIO4GZG+UccpH6LlFWk+QB4uEc7REsvmPMyAHvqoyy6JCLc0XJRj2zr/vDmyzx AGf244JUJjd9C/zRM0KQBdMSfbh/iOUkEGj4f6L9X+qtvGp/U3aNXQOZG2bHovYT Mk9pJYG4UBBQzdp2uPqQ2keSM4Kea5HrzHatSbCJZk9Oyxsg+JbET1teMBelZAoS 4SuO8llKPJ+fx/+Uk3lureS16PcqNlrUja5JLkDTMhVsbaHi/ZCgqsL1P7I8WgiR gFL8QMtsak4eUyxsYU+XPpyOPNO5Fe55IP66TNvcb8h937nAbevGn3+3e8Dz2Zoo X3b215TFht52ZFof2ilMdqA4NafCtIvCuSRPx2zRkvoTPl3WE7OyYNpEqqYuUyhq oh12imY/fkEh9hxgCl0Euo9SviOrwnR6KucPG8bIqm8DCjk9HKsivonkqoEd8EOM jWhdUTpSSpJT8Z+fiwJSPS5MD7GZVpc5E9NwG1y4xvWwq18ziMkgOmR6fwhnCQIV d8UfmHpqMLonZL+SydwF92TqZW1+gKUbkCoCCizS0ocVZ4oFIOYhAHjQv9LfXzVH lNNurgwIYkzyIZ4jURNR =vfaC -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of samplv1_0.3.3-1_amd64.changes
samplv1_0.3.3-1_amd64.changes uploaded successfully to localhost along with the files: samplv1_0.3.3-1.dsc samplv1_0.3.3.orig.tar.gz samplv1_0.3.3-1.debian.tar.gz samplv1_0.3.3-1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
samplv1_0.3.3-1_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 30 Jun 2013 22:23:40 +0100 Source: samplv1 Binary: samplv1 Architecture: source amd64 Version: 0.3.3-1 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org Changed-By: Alessio Treglia ales...@debian.org Description: samplv1- polyphonic sampler synthesizer Changes: samplv1 (0.3.3-1) unstable; urgency=low . [ Alessio Treglia ] * New upstream release. . [ Jaromír Mikeš ] * Added myself as uploader Checksums-Sha1: 61f37f14b6c4eb0c700265698c364be60cc473ed 2092 samplv1_0.3.3-1.dsc c5dafc3716b171e1c9fe5289e4d24fdc037c8222 130957 samplv1_0.3.3.orig.tar.gz fddac914508c55ff138db9251a5025457775d21f 2800 samplv1_0.3.3-1.debian.tar.gz ad9f31456ae6acacc9ed9d6c5832eb2902f0ad23 234488 samplv1_0.3.3-1_amd64.deb Checksums-Sha256: 04a8d237f0082048b9339ce5b152988615d33660a8097b8686892f2f56808a5e 2092 samplv1_0.3.3-1.dsc 00b199ed24e160763fb10a36942b8e79cbeabe861efe54b33a08bb21e5217f21 130957 samplv1_0.3.3.orig.tar.gz 84a41f3be8f963b61f84bbf59fc5cc8ed0700cdeb4c2cab1aafc53f6cec43bc3 2800 samplv1_0.3.3-1.debian.tar.gz 3d419678dc60b10d2add7439eb433992c170b938463a51bc9e3deb67c93206f8 234488 samplv1_0.3.3-1_amd64.deb Files: b5beaaae26f24bbc71abf450a7de6326 2092 sound optional samplv1_0.3.3-1.dsc 2540ab3ef3da39bd4da8a1ab8ff9334d 130957 sound optional samplv1_0.3.3.orig.tar.gz d28db300669cc1ead1f9a7d345148868 2800 sound optional samplv1_0.3.3-1.debian.tar.gz b58a2f5aa8bcf1c6fbe3f7681de44255 234488 sound optional samplv1_0.3.3-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJR0KVQAAoJEOikiuUxHXZaSB4P/ivOiLjLnnhFX+HsPmYHpU7p WXYXiFZFmbjzTdG6j5BWr0GHfcNnAXSK41LicFQ1+Z0qdczghVv5l7M7zcd3MHS7 J/2wus6EVsGMu4Cjg7Rxc5Xu1ApmXxAhh5qz24ZH91wir3yv6/s9jE1sp525FgIF 386FNZZi3RdeNGpK9mVaLiGZZ8aR3j0LXqUkErpjx9CzwhwX9Td83M0JnRerkJIF BmwASCX9bCpvlLoxl2PKEy26+zqhJEedgjtYFGqwnV1xX7pDROARUUhMgDa7zVpT hjxZFCsUTPcgYNmrD9OT7MmVvO830Zmenn4gznWqy4I1Qy77NgUabFixDalrGFrg SXC29eoHxS2DFMNunf3z6Ud/6KgU5Mbzq4UZhPjscZVMB88fXCh3PofUQmtD6gK7 fTEdYwrh66yJ0kgkSyptMEsa9aT16VJ/0mditH4AsjqDlYv/rqEkWSXXXUiM8RdZ DM9QIH6udDIT6yIAuiBYWcyjWpueNV0znyedBOz5EgO0DM6/IkyBpFHdgLxWElMT 8De6tQohMLRHTY7c9PYH2JkxXDJfEg8q1zKsS6jeyiXyK++qOfKbCQiiKjqR1LMN iM2lzUNZ4wPlPXhpEXkoHsL/1x4K/QFF+ESNqXvEJJFBAsHUVMo+GEb3On1XMC60 HTrSNGR6qJR/4uGVFk4n =eOZU -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] libav/experimental: sync to libnut, nom-num
On Sun, Jun 30, 2013 at 11:54 AM, siret...@users.alioth.debian.org wrote: The following commit has been merged in the experimental branch: commit d7d3efae82783a1533639c8c258dc61c4785e402 Author: Oded Shimon od...@ods15.dyndns.org Date: Sat Dec 23 12:33:37 2006 + This workflow makes the commits list unusable. Can we do anything to make it usable again? PS: does the new workflow provide benefits already? I imagine backporting fixes is made a lot easier now. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
spam bomb on pkg-multimedia-commits
Hi, I sincerely apologize for the spam bomb I have caused yesterday on pkg-multimedia-commits. I have used git-import-orig --upstream-vcs-tag parameter to import all upstream libav commits, and our commit hook happily send an email for all 32K commits upstream. This is clearly not acceptable, I really should have disabled the commit hook first. Since this process has turned out to be error prone, I think that maybe the commit hook can be made smarter to send out out a summary of changes instead of individual commit mails on merges? I figure it would be tricky to specify what the corner cases and in what case we want the commit diffs instead. Does anyone claim maintainership of the commit hooks, or shall I give it a shot? -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of synthv1_0.3.3-1_amd64.changes
synthv1_0.3.3-1_amd64.changes uploaded successfully to localhost along with the files: synthv1_0.3.3-1.dsc synthv1_0.3.3.orig.tar.gz synthv1_0.3.3-1.debian.tar.gz synthv1_0.3.3-1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
synthv1_0.3.3-1_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 01 Jul 2013 07:54:55 +0100 Source: synthv1 Binary: synthv1 Architecture: source amd64 Version: 0.3.3-1 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org Changed-By: Alessio Treglia ales...@debian.org Description: synthv1- old-school polyphonic synthesizer Changes: synthv1 (0.3.3-1) unstable; urgency=low . [ Jaromír Mikeš ] * Added myself as uploader . [ Alessio Treglia ] * New upstream release. Checksums-Sha1: 400af8e2682f86a21b820a615b1bb1baebd80c94 2092 synthv1_0.3.3-1.dsc 9cbf5276a2cdb5203dceeb30608a88e81a058cc8 124108 synthv1_0.3.3.orig.tar.gz 4adfee3c866828403d64e6e6b54dc812ae2d8dfe 2769 synthv1_0.3.3-1.debian.tar.gz ebd04d860eccc5ca0f9b8ae55991d0fe841c41eb 237422 synthv1_0.3.3-1_amd64.deb Checksums-Sha256: 630dd4fbbbf02d3d43a1efba95347ed3549f379b9e946a6e91fe59210bd70d31 2092 synthv1_0.3.3-1.dsc 116122dcbff24302ea10dc4ad9c835c94416c2870079e3f40f2ec8997d9b6846 124108 synthv1_0.3.3.orig.tar.gz e1c03bb8ea1b3074866be02480bdea858255f4d54ce14ef23e12c8f257f765b0 2769 synthv1_0.3.3-1.debian.tar.gz f9998e70eef35535e1e9795af5144535f24f6972d1e72e3663264d97a9624c81 237422 synthv1_0.3.3-1_amd64.deb Files: f77cc6cdf0a21e0b451a77e9c577899c 2092 sound optional synthv1_0.3.3-1.dsc 18bd21921ee65b718b2feb1d0ab03ac7 124108 sound optional synthv1_0.3.3.orig.tar.gz 2a28e9762aad44fc4bb3a79bb36f77e7 2769 sound optional synthv1_0.3.3-1.debian.tar.gz ae0d9621f7143b3fd736cba180c63dce 237422 sound optional synthv1_0.3.3-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJR0StRAAoJEOikiuUxHXZaiYwP/j+8FRbuCTV7lhoDyLZZh3j/ /0I5NJ+zkmWtAHt/M+WouYiSJBBwsf8qo7VedPvInUJBlTQgHHUFFqyY12VB4N1p ssTj0LoQ+AO2LEY32hHgq3enhUtpREyZMeINAfC/bC8gNatiGBiPDzdDsvrx+/5X 3mcy2jNdn60hSPOEXvHQr6jR3HKEdNEqmUjPTD62/PcFwUWeP33Zy98Bl7cUjPuv 8cqOowVZVuGUBJS0zWllzzEFRZkP1grCp0Is4xAP9zvmyKIvfg1RVVdJv7tzKtss 7QVdllaAc+UbXoatGN16+3mjZ7njkzBpYEfGGEsP1WRR/WrrBYVrprTbA3mdT7nA peNuB9wDWkQU32lbrJTM59PKi4hiq6KKEgzpDgxZW14X1AeQpcF+dAld495ZcqsV F8bV9SZyJzqPNFvI63xmKAvaJZAF1XNHY3F/X130DD7Nd9iKk2qVhwUevIYL/aWD fhR8jMHPZpEHXJZc/d21AjQ3jyLaWx5A7HBSluX4sB8eJgXm78P9q+ot0wqMU5vf UfUQ50pMNxIbHKYZXkAOCsAyhZ0ZqmtFlX+vG7LrWBid/eLy1LbM5USRjppuezGR cuf5Hbh/zRyBHvIJdSU1V83NDXWgl5yeoX8xxBlLAYrAizMr3eNvIfj/ocBaoaMb 6AYIumdc6SYoCrM1Yx55 =QIcz -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug report on pd-iemambi: iem_ambi.pd_linux crashes with exit status 139
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-06-26 19:44, Alexandre Rebert wrote: Hi, We found a crash in iem_ambi.pd_linux contained in the pd-iemambi package. You are being contacted because your are listed as one of the maintainer of pd-iemambi. as with the pd-readanysf package, i have prepared a package that fixes the reported problem. i also nagged upstream enough so they did a new release. it's all packaged in git+ssh://git.debian.org/git/pkg-multimedia/pd-iem_ambi - - this package uses CDBS - - it builds cleanly in a pbuilder/sid environment again, i would be grateful if somebody with upload permissions could review the package and upload it to unstable. cheers, fgasdmr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHRNLgACgkQkX2Xpv6ydvQLmgCgxt2HJZwwbXBqsDInJSrSHScj PEEAn3DQMg526zVCJqqOC/oA4SlsRgUX =cQE5 -END PGP SIGNATURE- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#686777: netjack2 + opus custom modes + debian
On 06/30/2013 03:11 AM, Ron wrote: My understanding of the background prior to that is that Robin had some discussion with some of the developers at FOMS, who at the time suggested the custom modes probably would be appropriate for the use described to them. correct. derf aka Tim Terriberry in this case. [..] The custom modes are not interoperable with anything else, nor are they a part of the codec standard, but they do exist in the code for people with very specialised needs in 'closed' applications, where the need for oddball frame sizes strongly outweighs any other considerations of interoperability, or codec performance (the latter being both in the sense of processing resources *and* more importantly audio quality). jack in particular was one of the use-cases for opus-devs to justify custom modes. My understanding at present is that the primary (only?) reason that netjack is using custom modes is so that it can use 64 sample frames which shaves ~1ms of latency off the usual 2.5ms (120 sample) minimum frame size for normal opus modes. We didn't quite get to the bottom of all of that before Robin had to leave, so at present my only understanding of the reason for that is that pro audio equipment can operate with lower latencies than normal sound cards which makes this desirable. not quite. netjack is using opus custom modes so that jack can use the same period-size across the complete jack system. Adding buffering on either side (sender + receiver) to align jack + opus buffers will always result in additional latency. For large jack buffersizes or long-distance communication that additional latency may be negligible, but it still is more latency. Furthermore, aligning non-audio jack-data (transport + MIDI) with sample accuracy to those opus-audio-buffers is far from trivial. It's not impossible, but it is quite complex because jack is not designed to cater for that case. What I still don't understand though is why if you are using Pro audio equipment the degradation in audio quality that this would bring (which is significant) would be acceptable for that use? a) because some users demand it :) b) because celt is no longer available on most distros low, fixed latency is most important. There are countless solutions for high-quality streaming - where latency and jitter is irrelevant, but basically only netjack that provides synchroneous low latency. [..] Which basically makes the question become: If you are using Pro audio equipment and ~1ms of latency does make a difference to you, then wouldn't a lossless transport mode be more appropriate for that anyway? on a LAN, yes lossless. Over Wifi it may make sense to compress lossy to accommodate more channels. On WAN there are e.g. remote jam-sessions, phone relays, live monitoring,.. - none of which requires high quality, but all require fixed low latency. [..] The upstream developers have reaffirmed that they definitely do not want to enable the custom modes by default in what they release, so even if we do override that here for the .debs, there'll still be a question of our compatibility with other distros and users. yes, the solution for that would be to add opus as git-submodule to jack and statically link netjack against it. That'd also accommodate windows, OSX and *BSD builds of jackd. [..] - Can jack really make a case for needing this in a way that actually delivers real benefits to jack users. (Robin has said that this is also 'complicated', but I still don't fully understand why yet). see above. Sample-sync alignment with other data-types is not easy. Asynchronous (buffered) communication is orthogonal to everything else in jack. It will likely be rejected upstream. jack does not aim to do everything. JACK tries to address 95% and do that right and not care about the last 5% edge-cases. On top of of that, there are currently no volunteers to implement vanilla opus on netjack2 (and also no volunteer to implement that in netjack1). I was scratching my own itch with netjack2+opus. works for me. The only case for non-custom modes would be: 1) interoperability with other opus apps 2) higher quality encoding (1) is never going to work out. netjack consists of N audio-channels, M midi-channels. Both include per-port latencies (min,max). And netjack also comprises transport information (timecode, tempo, bar-beat-tick, audio-frames per video-frame, etc). It is not a data stream that will be consumed by non-jack. (2) if a user chooses lossy encoding s/he does not really care about quality anyway. jack's main features is no-copy zero-latency with local clients, being able to include remote clients on the network that align sample-sync and respond reliably is the main use-case. ciao, robin ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org
документ эксперта МБА
для тех, кто желает бытовать успешным http://bit.ly/127Hg07 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: spam bomb on pkg-multimedia-commits
On Mon, Jul 1, 2013 at 6:30 AM, Reinhard Tartler siret...@gmail.com wrote: Since this process has turned out to be error prone, I think that maybe the commit hook can be made smarter to send out out a summary of changes instead of individual commit mails on merges? I definitely second this :) Does anyone claim maintainership of the commit hooks, or shall I give it a shot? Please go ahead! -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] libav/experimental: sync to libnut, nom-num
Quoting Felipe Sateler (2013-07-01 00:39:07) On Sun, Jun 30, 2013 at 11:54 AM, siret...@users.alioth.debian.org wrote: The following commit has been merged in the experimental branch: commit d7d3efae82783a1533639c8c258dc61c4785e402 Author: Oded Shimon od...@ods15.dyndns.org Date: Sat Dec 23 12:33:37 2006 + This workflow makes the commits list unusable. Can we do anything to make it usable again? The Perl team faced similar frustration (around the time I started to do same - not sure if only I was to blame there) for their irc bot. That has now been improved to abbreviate 9+ commits (or something like that, I don't know the details). Perhaps their code can be reused for whatever has been put into place for spewing out to -commit mailinglist. PS: does the new workflow provide benefits already? I imagine backporting fixes is made a lot easier now. Yes, that's one detail of a larger benefit as I see it: Being able to easily follow what changes within each upstream change, and why. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: spam bomb on pkg-multimedia-commits
On Mon, Jul 1, 2013 at 1:30 AM, Reinhard Tartler siret...@gmail.com wrote: Since this process has turned out to be error prone, I think that maybe the commit hook can be made smarter to send out out a summary of changes instead of individual commit mails on merges? I figure it would be tricky to specify what the corner cases and in what case we want the commit diffs instead. I was thinking that maybe we should only report on commits touching the debian/ folder. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: nekobee and ladspa-sdk DM flag
Hi Jaromir, sorry for the delay What is your key ID? On Thu, Jun 13, 2013 at 7:11 PM, Jaromír Mikeš mira.mi...@gmail.com wrote: I would like to upload nekobee and ladspa-sdk. Can someone set DM flag for me? best regards mira ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: spam bomb on pkg-multimedia-commits
On Mon, Jul 1, 2013 at 3:14 PM, Felipe Sateler fsate...@debian.org wrote: I was thinking that maybe we should only report on commits touching the debian/ folder. Yeah, it looks redundant to me to forward upstream commits to our -commit list. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#686777: netjack2 + opus custom modes + debian
On Mon, Jul 01, 2013 at 11:15:10AM +0200, Robin Gareus wrote: On 06/30/2013 03:11 AM, Ron wrote: My understanding of the background prior to that is that Robin had some discussion with some of the developers at FOMS, who at the time suggested the custom modes probably would be appropriate for the use described to them. correct. derf aka Tim Terriberry in this case. Right, and it was Tim who ran through the math in the IRC discussion to point out that this might not have been the best suggestion after all. The custom modes are not interoperable with anything else, nor are they a part of the codec standard, but they do exist in the code for people with very specialised needs in 'closed' applications, where the need for oddball frame sizes strongly outweighs any other considerations of interoperability, or codec performance (the latter being both in the sense of processing resources *and* more importantly audio quality). jack in particular was one of the use-cases for opus-devs to justify custom modes. Greg was probably the one who most often raised oddball cases that might use this, but even he was now scratching his head somewhat at what you are actually trying to achieve with using it for netjack as you are. Which is why I wanted to try to get to the bottom of your rationale here. My understanding at present is that the primary (only?) reason that netjack is using custom modes is so that it can use 64 sample frames which shaves ~1ms of latency off the usual 2.5ms (120 sample) minimum frame size for normal opus modes. We didn't quite get to the bottom of all of that before Robin had to leave, so at present my only understanding of the reason for that is that pro audio equipment can operate with lower latencies than normal sound cards which makes this desirable. not quite. netjack is using opus custom modes so that jack can use the same period-size across the complete jack system. What gets to pick the period here? Even custom modes still limit you to some discrete number of choices, it isn't continuously variable, so there will surely still be cases where some part of the system needs to adapt to suit other parts if this is to be true, won't there? Adding buffering on either side (sender + receiver) to align jack + opus buffers will always result in additional latency. For large jack buffersizes or long-distance communication that additional latency may be negligible, but it still is more latency. You realise that we are talking about a latency that is equivalent to moving your head approximately 15 inches from your speakers, right? Or in the case of a 'jam session', two players standing about a foot from each other ... with their instruments held a foot from each others chins. If they are any further apart than that, in the same room, then the latency difference that you are worrying over here becomes insignificant by comparison. If they stand a guitar length apart and put headphones on, even the normal mode of opus will get the sound to their ears faster than the air between them would. It doesn't take large buffer sizes or long distances to make this negligible. We're not talking coarse yak hairs here, it's the finest angora. Furthermore, aligning non-audio jack-data (transport + MIDI) with sample accuracy to those opus-audio-buffers is far from trivial. Elastic stores really are trivial. So I'm still not really sure what showstopper complexity you are worried about there. What I still don't understand though is why if you are using Pro audio equipment the degradation in audio quality that this would bring (which is significant) would be acceptable for that use? a) because some users demand it :) What exactly are users demanding here? They surely aren't demanding that members of the band stand on each others toes and play their guitars with their teeth. If they want to use oxygen free copper that's fine, but what _real_ gain are they demanding to get here? That's the important question we need to answer. b) because celt is no longer available on most distros It arguably should have never been available on them in the first place :) But that was a learning experience for us too! low, fixed latency is most important. There are countless solutions for high-quality streaming - where latency and jitter is irrelevant, but basically only netjack that provides synchroneous low latency. You can still have low latency with standard opus modes. If you take one small step toward your speaker it can even be lower than the custom mode you are currently using :) Which basically makes the question become: If you are using Pro audio equipment and ~1ms of latency does make a difference to you, then wouldn't a lossless transport mode be more appropriate for that anyway? on a LAN, yes lossless. Over Wifi it may make sense to compress lossy to accommodate more channels. On WIFI it's pointless to talk about
Re: Bug#686777: netjack2 + opus custom modes + debian
On Mon, Jul 01, 2013 at 04:40:19PM +0200, Adrian Knoth wrote: On 06/30/2013 03:11 AM, Ron wrote: Hi! I'll limit my response to the aspect of symbols, since Robin has already answered the other questions. Just sketching now: libopus0 will provide /usr/lib/libopus.so.0 (business as usual) libopus-custom-0 will provide /usr/lib/libopus-custom.so.0 The big problem with this is that both of those will provide all of the functions that libopus.so.0 does, only some of the symbols with the same names will have different implementations in the -custom one. Which means that when jack links to -custom, and jill links to -vanilla, and then some high level audio app or desktop environment or whatever links to both jack and jill ... hilarity is likely to ensue. I've seen colliding symbols with ardour via indirect linking, and it's really a PITA to diagnose. But here it seems to be very unlikely: only the jack server links against libopus(-custom), and this server is a standalone binary that's not linking or linked to anything else. All the clients link against libjack, and even if they do link against libopus, they're not interfering with the server's libopus-custom, since client-server communication is done via /dev/shm. So I think we can ignore the symbol aspect for all practical cases. (Correct me if I'm wrong). Where does libjacknet.so.0.1.0 fit into all of that? I don't think we can guarantee that for the forever future something using the custom modified symbols would be compatible with the normal builds. Optimisation work is really only just beginning, and there are quite a few places where the normal code might diverge in newly incompatible ways from what is possible when custom is enabled, and where a symbol collision could be even worse than it is at present. This could turn into a snowball of ugly pretty easily I fear ... Which is why I'm really keen to be sure we're not going down this path for something so tiny that nobody will ever be able to hear it. Cheers, Ron ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
[bts-link] source package vlc
# # bts-link upstream status pull for source package vlc # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #699832 (http://bugs.debian.org/699832) # Bug title: vlc-nox: document VLC_PLUGIN_PATH environment variable # * http://trac.videolan.org/vlc/ticket/8835 # * remote status changed: (?) - new usertags 699832 + status-new # remote status report for #704221 (http://bugs.debian.org/704221) # Bug title: vlc: doesn't document cdda:// # * http://trac.videolan.org/vlc/ticket/8834 # * remote status changed: (?) - new usertags 704221 + status-new # remote status report for #708953 (http://bugs.debian.org/708953) # Bug title: vlc: VLC open in single instance mode doesn't play files opened from nautilus Open with VLC # * http://trac.videolan.org/vlc/ticket/8839 # * remote status changed: (?) - closed # * remote resolution changed: (?) - fixed usertags 708953 + status-closed resolution-fixed thanks ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of openni_1.5.4.0-7_amd64.changes
openni_1.5.4.0-7_amd64.changes uploaded successfully to localhost along with the files: openni_1.5.4.0-7.dsc openni_1.5.4.0.orig.tar.gz openni_1.5.4.0-7.debian.tar.gz libopenni0_1.5.4.0-7_amd64.deb libopenni-java_1.5.4.0-7_amd64.deb openni-utils_1.5.4.0-7_amd64.deb libopenni-dev_1.5.4.0-7_amd64.deb openni-doc_1.5.4.0-7_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
openni_1.5.4.0-7_amd64.changes is NEW
binary:libopenni-java is NEW. binary:openni-doc is NEW. binary:openni-utils is NEW. binary:libopenni-dev is NEW. binary:libopenni0 is NEW. source:openni is NEW. Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
TNS Evaluating Research Inc.® (RECRUITING NOW)!
Greetings, A position is currently available for any individual in the UNITED STATES/UNITED KINGDOM/EUROPE who is interested in becoming an evaluator/Secret shopper. REQUIREMENTS 1. Minimal Computer usage skill e.g Desktop, Laptop or Mobile phone. 2. To become a mystery shopper with TNS Evaluation Research you must be over the age of 18 and all you need to do is to register with us today by providing your details below and start shopping Evaluation! Kindly reply with the basic information below to get started. Full Name... Full Address ... City: State: Zip Code Mobile/Home number (s)... Email Address We're looking for thousands of participants to become mystery shoppers,tell us about their experiences in shops, pubs, clubs, hotels and many more places It is a flexible, fun and rewarding job. There is no charge to become part of our teams. You do not need previous experience, US Applicants would be paid $200 For Two Surveys Per Day; $600 for 3 days surveys completed in a week and UK/EUROPE Applicant would be paid 200 pounds for two Surveys per Day; $600 for 3 days surveys completed in a week NB: Only participants who replies or responds with their informations above would be taken seriously. If you did not request this subscription, please accept our apologies and simply ignore this message. Warm Regards. Daniel Brown Recruitment officer/Payment Co-ordinator TNS Evaluating Research Inc.® ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
