similar to: Opus codec in Debian?

I've created a blog entry about my XCP on Debian wheezy experiences http://danielpocock.com/migrating-to-xen-cloud-platform-on-debian-wheezy Please let me know if anything is inaccurate or could be explained better. I'm quite happy to add links out to other resources that are up to date.

Package: xen-utils-4.1 Version: 4.1.4-3+deb7u4 Severity: serious Tags: patch dom0 running wheezy domU upgraded from wheezy to jessie. The domU doesn't boot any more, errors: Error code: Using <class 'grub.GrubConf.Grub2ConfigFile'> to parse /grub/grub.cfg Error parameters: Traceback (most recent call last):, File "/usr/lib/xcp/lib/pygrub.xcp", line 853, in

I created a 1TB RAID1. So far it is just for testing, no important data on there. After a reboot, I tried to mount it again # mount /dev/mapper/vg00-btrfsvol0_0 /mnt/btrfs0 mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg00-btrfsvol0_0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or

Package: xcp-xe Version: 1.3.2-14 Severity: important My dom0 is 64 bit wheezy with the xen-xapi environment I try the following: xe vm-install \ template=Debian\ Wheezy\ 7.0\ \(64-bit\) new-name-label=wheezytest1 xe vm-param-set uuid=$MY_UUID \ other-config:install-repository=http://ftp.ch.debian.org/debian/ xe vif-create network-uuid=$MY_NET_UUID \ vm-uuid=$MY_UUID device=0 xe

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 26/04/15 10:45, Bastian Blank wrote: > Hi Daniel > > On Sun, Apr 26, 2015 at 10:35:01AM +0200, Daniel Pocock wrote: >> This should probably be released in an update to wheezy. > > Well, if you can pursuade the release team. We have grub2 for Xen > in Jessie now and it can be used on Wheezy as well. > Can you be

On 14/05/16 19:35, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Sat, 2016-05-14 at 19:10 +0200, Daniel Pocock wrote: >> If somebody is still running wheezy for their dom0 (host) environment >> and they are using jessie or other systems with grub2 in their VMs, they >> can't boot their VM. >> >> A rather trivial 1-line fix in the dom0

Package: release.debian.org Severity: normal Tags: wheezy User: release.debian.org at packages.debian.org Usertags: pu X-Debbugs-CC: pkg-xen-devel at lists.alioth.debian.org If somebody is still running wheezy for their dom0 (host) environment and they are using jessie or other systems with grub2 in their VMs, they can't boot their VM. A rather trivial 1-line fix in the dom0 (host) system

Hi, folks, I have an old CELT thing that I'm updating to Opus and I'm trying to get individual pieces upgraded.  My first task is upgrading the CELT encoder to Opus. The old CELT thing treated the L and R channels as independent mono streams, encoded them somehow with CELT to form one bitstream, sent one bitstream across, and then unpacked it manually after the decoder. Can I do that

I downloaded test vectors from opus-codec.org site. The site indicated that the test files are intended for verifying that the Opus decoders are operating properly. I assume I could also use them to verify my encoder implementation, right? For example, use testvector01.dec as input to my encoder and compare its output bitstream with the corresponding testvector01.bit bitstream file. Any idea

Hi, I've been testing the Debian packages ahead of the Debian 7 release (which is very imminent) I believe this is a serious bug[1] in the package, as it appears that HVM networking is broken, or at the very least, requires some undocumented configuration step Specifically: - I can start the HVM domU without any vif - if I attach a vif, the domU will not start Looking at

Benjamin, Thanks for the prompt response. Are there other recommended methods to verify encoder implementations? Regards, Chris From: benjamin.m.schwartz at gmail.com [mailto:benjamin.m.schwartz at gmail.com] On Behalf Of Benjamin Schwartz Sent: Sunday, November 10, 2013 1:53 PM To: Wang, Chris Cc: opus at xiph.org Subject: Re: [opus] Questions Regarding Opus Test Vectors On Sun, Nov 10,

Hi there, I'm not sure what the right place would be, please direct me to where is most appropriate if not this list. I am currently working on a codec designed for karaoke and text information, to be embedded in an Ogg container. It includes text, motion information, and style/placement. At the moment, the bitstream design is still in flux, but draws heavily from Vorbis and Theora, while

Hi Christian, Thanks for publishing this. Do you happen to have some numbers on what the expected bit error rates are for a "typical AMR-WB usage scenario"? I'm curious about that because you note that the Opus bitstream wasn't designed to be inherently robust against a bit error at any point in the packet (and some places will obviously effect it worse than others) - however

FYI, the Ogg Opus encapsulation is now RFC 7845: https://tools.ietf.org/html/rfc7845 -------- Forwarded Message -------- Subject: [codec] RFC 7845 on Ogg Encapsulation for the Opus Audio Codec Date: Fri, 29 Apr 2016 19:47:28 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: drafts-update-ref at iana.org, codec at ietf.org, rfc-editor at

Hi, I've been studying the Opus code and documentation for a while and have seen it mentioned several times that Opus uses pre-skip to allow the codec to converge. What convergence are they referring to? Rate control? Energy envelope prediction after seeking? Is there a discussion of this somewhere? Also, I'm also interested in the seeking behaviour of the decoder. If, say, I want to

hey, I'm using samba version 3.6.6 on debian wheezy and windows 7 clients with office 2010, on my samba share I've the following settings: [cad] comment = CAD path = /mnt/samba-daten/work/webdav/cad writable = yes valid users = root, @cad, @fg-domuser admin users = abc, def, ghi create mask = 0770 force create mode = 0770 directory mask = 0770 force directory mode = 0770 veto

My impression of this bug is that HVM networking is not possible with XCP, or at least it is not possible without some undocumented configuration setting or missing dependency package If there is a workaround from upstream, I would propose lowering the severity to important again. I am happy to test any proposed work around and provide quick feedback. The log output in my previous post suggests

A few random observations: 1. Clang could do better with large but boring switches like this: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/E8/E88C5111.shtml Performance of clang's output will be fine but this is a major code size lose. 2. Destruction of stupid loops is incomplete, sometimes due to phase ordering problems:

Hi Thomas, > Do you have the infrastructure to stay current and rebuild e.g. on > dependency changes? Yes, we use pbuilder-dist for this. We are providing backports of related packages including liquidsoap, silan (a new silence detector application), and libopus0, as well as Airtime itself. > Actually I now wonder if using OBS could make this task easier. We could > have a community

as per yesterday's discussion at #theora -- It has been suggested that we devise a method such that we will be able to add certain features to the bitstream (interlace, exotic color subsampling, clip length flag for download, etc), in such a way as to not obsolete streams encoded previously. Rillian's suggestion, which is pretty much standard practice, is to add a bitstream revision