search for: bowery

Following the directions in: http://www.xml.com/pub/a/2006/04/19/rest-on-rails.html?page=2 I get through the: rake db:migrate With the tables created properly but then when I run the: rake test:units I get a failure: ActiveRecord::StatementInvalid: RuntimeError: ERROR C23502 Mnull value in column "title" violates not-null constraint FexecMain.c L1750

Has anyone tried hacking the fork out of Webrick''s servlet dispatch code so that ruby -r can be used to debug rails apps? -- Posted via http://www.ruby-forum.com/.

Hi Jean-Marc, I looked at that but importantly these streams need to remain absolutely independent, Further they may have been encoded at some previous time. So my question stands. Thanks, Marc On Jul 26, 2013, at 9:10 PMEDT, Jean-Marc Valin wrote: > Hi Marc, > > I recommend you have a look at the multistream API and how we use it for > surround in the Ogg Opus draft. Sounds

I have run a few more test at different bitrates and 1.1 is looking even worse in terms of speed compared to previous versions. I have shared a google sheet which has the raw data and charts for 6,16 and 32 kbps. Unfortunately you cannot show proper error bars on Google sheets but the standard deviation is in the data if you want to look. You can see that the profile for 1.1 is a lot different

How does one go about troubleshooting a "Routing Error" "Recognition failure"? I''ve used the Webrick log to get down to a "recognize_path(path)" call in /actionpack-1.12.1/lib/action_controller/routing.rb and put a logger.debug path there, but that just told me what I already knew, and the definition of "recognize_path" looks like its

I'm curious what happens if you feed an inaccurate value to 'expected loss'? Channel loss rate isn't always easy to measure, esp. in real time. I'm trying to figure out, ultimately, is it a better strategy to put the worse case expected loss in there, or more like the best case? (dealing with audio/full bandwidth here) thanks, Marc

Thanks for the answers Benjamin? On Jun 14, 2013, at 8:05 PMEDT, Benjamin Schwartz wrote: > I have flexibility in the frame sizes of the unencoded audio, and packet sizes on the RF link. > > This implies that you don't have a very tight latency constraint, so you can afford to run a resampler. > I assume the resample costs CPU cycles? the RX is battery powered, I'd just as

I can't quite figure this out from looking at the repacketizer code. Let's say I have 4 separate stereo streams (say from an 8 channel converter) and want to transmit them somewhere in one stream e.g. RTP or the like. (assuming, custom format if necessary) So could I merge 4 packets with the repacketizer, TX the merged packets, on the other side RX them then split them with the

I didn't expect this, is it normal? When you use inbandfec, and have packet losses, you end up with more audio samples than you started with. With short frame (2.5), the FEC isn't supposed to do anything but it shouldn't do that should it? and 20mS frame, should do 'something' but? add audio? I'm using opus_demo for this. Here's the steps (I have my test audio in

Hi Jean-Marc, On Jun 15, 2013, at 12:20 PMEDT, Jean-Marc Valin wrote: > > >> So I still wonder, if you set up a custom mode, but then had all the >> settings the same as a normal mode, would the codec perform worse, or >> the same? > > You'll have to try normal vs custom modes and choose. The only thing I'm > telling you is don't run a 48 kHz

Hi Jean-Marc, On Jun 15, 2013, at 2:23 AMEDT, Jean-Marc Valin wrote: >> I'm looking at how to run Opus at 44.1K. I have flexibility in the >> frame sizes of the unencoded audio, and packet sizes on the RF link. > > You should probably consider resampling. It's not that expensive and it > would make things easy. But otherwise, see below. Yes, considering your and

Hi all, I'm implementing the opus codec for a proprietary RF link (for fullband audio) and want to make sure I understand something. The link is currently running at 44.1KHz - realtime (i.e. streaming from an A/D at one side, ultimately to a D/A at the other). Rather than muck with all the infrastructure, I'm looking at how to run Opus at 44.1K. I have flexibility in the frame sizes of

It might be good to use the (uncompressed) samples on the opus page, as a common starting point? http://www.opus-codec.org/examples/ On Dec 21, 2013, at 9:43 AMEST, Stuart Marsden wrote: > I have run a few more test at different bitrates and 1.1 is looking even worse in terms of speed compared to previous versions. > > I have shared a google sheet which has the raw data and charts for