11

I've been playing around with ruby recently, and I decided to start a simple project to write a ruby script that records line-in sound to a .wav file. I discovered that ruby doesn't provide very good access to hardware devices (and it probably shouldn't), but that PortAudio does, and I discovered a great wrapper for PA here (it is not a gem, I think because it uses ruby's ffi to attach to PortAudio, and the PA library could be in a variety of places). I've been muddling through PortAudio's documentation and examples to figure out how PA works. I haven't written or read C in years.

I'm running into difficulty with what parameters I should be passing to a stream during creation, and a buffer during creation. For example, what exactly is a frame, and how is it related to other parameters like channel and sample rate. I'm totally new to audio programming in general as well, so if anyone could point me to some general tutorials, etc, about device level audio, I'd appreciate it.

ruby-portaudio provides a single example that creates a stream and a buffer, writes a sin wave to the buffer, then sends the buffer to the stream to be played. Some of the ruby I'm having trouble with in the example, specifically the loop block.

  PortAudio.init

  block_size = 1024
  sr   = 44100
  step = 1.0/sr
  time = 0.0

  stream = PortAudio::Stream.open(
             :sample_rate => sr,
             :frames => block_size,
             :output => {
               :device => PortAudio::Device.default_output,
               :channels => 1,
               :sample_format => :float32
              })

  buffer = PortAudio::SampleBuffer.new(
             :format   => :float32,
             :channels => 1,
             :frames   => block_size)

  playing = true
  Signal.trap('INT') { playing = false }
  puts "Ctrl-C to exit"

  stream.start

  loop do
    stream << buffer.fill { |frame, channel|
      time += step
      Math.cos(time * 2 * Math::PI * 440.0) * Math.cos(time * 2 * Math::PI)
    }

    break unless playing
  end

  stream.stop

If I'm going to be recording, I should be reading a stream into a buffer, then manipulating that buffer and writing it to file, right?

Also, if I'm barking up the wrong tree here, and there is an easier way to do this (in ruby), some direction would be nice.

oflannabhra
  • 661
  • 5
  • 18
  • Seems to be a related (not dupe) question here http://stackoverflow.com/questions/2716987/recording-audio-through-rtmp-rails – ted.strauss Aug 09 '12 at 20:38

1 Answers1

3

Let's first clarify the terms you were asking about. For this purpose i will try to explain the audio pipeline in a simplified way. When you are generating a sound as in your example, your sound card periodically requests frames (= buffers = blocks) from your code, which you fill with your samples. The sampling rate defines how many samples you provide within a second and thus the speed with which your samples are played back. The frame size (= buffer size = block size) determines how many samples you provide in one request from the sound card. A buffer is typically quite small, because the buffer size directly affects the latency (large buffer => high latency) and large arrays can be slow (especially ruby arrays are slow).

Similar things happen when you are recording sound from your sound card. Your function gets called every now and then, and the samples from the microphone are typically passed in as an argument to the function (or even just a reference to such a buffer). You are then expected to process these samples, e.g. by writing them to disk.

I know that the thought of "doing everything in Ruby" is quite tempting, because it is such a beautiful language. When you are planning on doing audio processing in real time, i would recommend to switch to a compiled language (C, C++, Obj-C, ...) though. These can handle audio much better, because they're much closer to the hardware than Ruby and thus generally faster, which can be quite an issue in audio processing. This is probably also the reason why there are so few Ruby audio libraries around, so maybe Ruby just isn't the right tool for the job.

By the way, i tried out ruby-portaudio, ffi-portaudio as well as ruby-audio and none of them were working properly on my Macbook (tried to generate a sine wave) which sadly shows again, how Ruby is not capable of handling this stuff (yet?).

Patrick Oscity
  • 53,604
  • 17
  • 144
  • 168
  • If you can mess with audio through a gui, you can mess with it through a scripting language. For example, Pure Data is a fun graphical audio programming language that, sure enough, at least one person is trying to [drive with Ruby](http://matschaffer.com/2010/11/ruby-midi-pure-data/). I'm sure there are similar efforts with [other audio synthesis environments](http://en.wikipedia.org/wiki/Comparison_of_audio_synthesis_environments). – mgamba Dec 31 '12 at 14:34
  • But that would just be a wrapper around a performance tuned library that handles the actual synthesis, right? I was rather referring to a pure Ruby approach. – Patrick Oscity Mar 28 '13 at 20:17
  • Here's some Ruby code to output to .wav: https://github.com/cohena/RAFL/blob/master/RAFL_wav.rb – mgamba Mar 29 '13 at 16:33
  • Yes, i’ve done stuff like this, too (https://gist.github.com/padde/926014) but the above question is about live audio, not recording to a file. – Patrick Oscity Mar 30 '13 at 11:32
  • 1
    The exact wording of the first sentence is `write a ruby script that records line-in sound to a .wav file`. – mgamba Mar 31 '13 at 03:16
  • That is right, but the code using portaudio suggests a live audio solution. Now that i think of it, it really isnt clear whether it is a requirement that the audio be generated in real time. Sorry, didn't mean to offend you! – Patrick Oscity Mar 31 '13 at 10:50
  • No offense taken. If you're just looking at the code, that's a reasonable assumption. – mgamba Mar 31 '13 at 14:18
  • Yeah, it was for a live audio situation. I needed to sample live audio, write that sample to a file, then perform analysis on it while continuing to sample. I ended up writing a solution with Objective-C, actually. – oflannabhra Sep 02 '15 at 14:05