File: [local] / www / faq / faq13.html (download) (as text)
Revision 1.228, Mon Apr 10 02:55:09 2023 UTC (13 months, 4 weeks ago) by tj
Branch: MAIN
CVS Tags: HEAD
Changes since 1.227: +3 -3 lines
7.3 updates
|
<!doctype html>
<html lang=en id=faq>
<!-- If you make edits to any FAQ documents, please start each sentence
on a new line, and try to keep the general formatting consistent
with the rest of the pages -->
<title>OpenBSD FAQ: Multimedia</title>
<meta charset=utf-8>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" type="text/css" href="../openbsd.css">
<link rel="canonical" href="https://www.openbsd.org/faq/faq13.html">
<style>
table {
border-collapse: collapse;
empty-cells: show;
margin-top: 1em;
}
td {
text-align: center;
border: #000 1px solid;
}
</style>
<!--
Copyright (c) 2005-2007 Steven Mestdagh <steven@openbsd.org>
Permission to use, copy, modify, and distribute this documentation for
any purpose with or without fee is hereby granted, provided that the
above copyright notice and this permission notice appear in all copies.
THE DOCUMENTATION IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
WARRANTIES WITH REGARD TO THIS DOCUMENTATION INCLUDING ALL IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS DOCUMENTATION
-->
<h2 id=OpenBSD>
<a href="../index.html">
<i>Open</i><b>BSD</b></a>
FAQ - Multimedia
<small>
<a href="index.html">[FAQ Index]</a>
</small>
</h2>
<hr>
<ul>
<li><a href="#enablerec" >Enabling Audio Recording</a>
<li><a href="#confaudio" >Configuring Audio Hardware</a>
<li><a href="#audiolevel" >Adjusting Audio Levels</a>
<li><a href="#usbaudio" >Using a USB Audio Interface</a>
<li><a href="#playaudio" >Playing Audio Files</a>
<!-- XXX
<li><a href="#playCD" >Playing Audio CDs</a>
XXX -->
<li><a href="#recordaudio">Recording Audio Files</a>
<li><a href="#recordmon" >Recording a Monitor Mix of All Audio Playback</a>
<li><a href="#audiolat" >Lowering Audio Latency</a>
<li><a href="#audionet" >Using Remote Audio Hardware</a>
<li><a href="#default" >Choosing the Default Audio Device</a>
<li><a href="#audioprob" >Debugging Audio Problems</a>
<li><a href="#midi" >Using MIDI Instruments</a>
<li><a href="#webcam" >Using a Webcam</a>
<!-- XXX
<li><a href="#playDVD" >Playing DVDs</a>
<li><a href="#burnCD" >Burning CDs and DVDs</a>
<ul>
<li><a href="#burnIntro" >Introduction and Basic Setup</a>
<li><a href="#writeCD" >Writing CDs</a>
<li><a href="#writeDVD" >Writing DVDs</a>
</ul>
<li><a href="#plugins" >Browser Plugins (Java and Flash)</a>
XXX -->
</ul>
<hr>
<h2 id="enablerec">Enabling Audio Recording</h2>
For privacy reasons, audio recording is disabled by default in OpenBSD.
The <code>kern.audio.record</code> sysctl may be used to enable it.
<pre class="cmdbox">
# <b>sysctl kern.audio.record=1</b>
# <b>echo kern.audio.record=1 >> /etc/sysctl.conf</b>
</pre>
<h2 id="confaudio">Configuring Audio Hardware</h2>
Each sound card model has its own set of controls.
Some have no controls at all; others have a hundred or more.
Running <a href="https://man.openbsd.org/mixerctl">mixerctl(8)</a> as root
will list all of the controls and current settings.
<p>
Not every option of every audio chip necessarily reaches the outside world.
There may be, for example, more outputs listed than are physically connected.
The controls of an audio device may be labeled differently.
Usually the controls have a meaningful label, but sometimes one must simply
try different settings to see what effect each control has.
<p>
Here's a list of controls to consider:
<p>
<strong>Mute and Level controls</strong> -
Even if the main controls seem to be properly set, there might be
multiple mute or level controls in the signal path.
In the example below, the device has a master recording level and a
microphone gain control:
<pre class="cmdbox">
record.adc-0:1=248,248
record.adc-0:1_source=mic
inputs.mic=85,85
</pre>
<strong>External Amplifier Power-Down (EAPD)</strong> -
This switch is typically used for power saving in laptops and may need
to be set to get an output signal:
<pre class="cmdbox">
outputs.spkr_eapd=on
</pre>
<strong>Recording Source</strong> -
Some devices have multiple microphone inputs.
Examples of such controls:
<pre class="cmdbox">
record.source=mic
record.adc-0:1_source=mic
</pre>
To make the changes take effect on each reboot, edit the
<code>/etc/mixerctl.conf</code> file.
For example:
<pre class="cmdbox">
record.adc-0:1_source=mic
inputs.mic=85,85
</pre>
<h2 id="audiolevel">Adjusting Audio Levels</h2>
The <a href="https://man.openbsd.org/sndioctl">sndioctl(1)</a>
utility is used to manipulate audio controls as a regular user.
Running it with no arguments will list all the controls and current settings.
<p>
The <code>output.level</code> control is always present.
It either corresponds to a hardware control or is emulated in software.
<h2 id="usbaudio">Using a USB Audio Interface</h2>
An example of a USB audio interface in a dmesg output might look like this:
<pre class="cmdbox">
uaudio0 at uhub2 port 1 configuration 1 interface 1 "ABC C-Media USB Audio Device" rev 1.10/1.00 addr 2
uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 8 ctls
audio1 at uaudio0
</pre>
On most systems, the first audio device is the internal sound card.
A USB audio device then becomes the second one when connected.
In the default <a href="https://man.openbsd.org/sndiod">sndiod(8)</a>
configuration, both devices are known to programs as
<code>snd/0</code> and <code>snd/1</code>
respectively and may be used independently.
<p>
Programs will use <code>snd/default</code>, which points to
<code>snd/0</code>, by default.
This binding can be quickly changed using <code>server.device</code>
like so:
<pre class="cmdbox">
$ <b>sndioctl server.device=1</b>
</pre>
Alternatively, <a href="https://man.openbsd.org/sndiod">sndiod(8)</a> may be
configured to make <code>snd/default</code> correspond to the USB device when
it's connected or to the internal one when it's not:
<pre class="cmdbox">
# <b>rcctl set sndiod flags -f rsnd/0 -F rsnd/1</b>
# <b>rcctl restart sndiod</b>
</pre>
When the server opens the device, it will first try the USB one.
If it's not present, the internal one is used instead.
If the USB device is disconnected, sndiod attempts to continue operation
using the internal sound card.
If the USB device is connected again, sndiod will see it
the next time it attempts to open the device.
To force sndiod to switch between devices, reload the server:
<pre class="cmdbox">
# <b>rcctl reload sndiod</b>
</pre>
<h2 id="playaudio">Playing Audio</h2>
<p>
OpenBSD comes with <a href="https://man.openbsd.org/aucat">aucat(1)</a>,
a program able to play uncompressed WAV, AIFF and AU files.
It can be used in very simple cases or to test playback:
<pre class="cmdbox">
$ <b>aucat -i filename.wav</b>
</pre>
There are many other players available as <a href="faq15.html">packages</a>
that support other audio formats.
<!-- XXX
<h2 id="playCD">Playing Audio CDs</h2>
XXX -->
<h2 id="recordaudio">Recording Audio</h2>
Once recording is enabled with the <code>kern.audio.record</code> sysctl,
<a href="https://man.openbsd.org/aucat">aucat(1)</a>
can be used for recording uncompressed WAV, AIFF and AU files.
<pre class="cmdbox">
$ <b>aucat -o file.wav</b>
</pre>
The above command will start the recording of a file in WAV format.
Press CTRL+C to finish the recording.
<p>
To play the file back, run:
<pre class="cmdbox">
$ <b>aucat -i file.wav</b>
</pre>
If recording seemed to work, but playback of the recording was silent or
not what was expected, the mixer probably needs some configuration.
Make sure that you select the right source to record from and that it
is unmuted.
<p>
If needed, the resulting WAV file could be compressed with the
appropriate program from the ports tree.
Alternatively, ports like sox, ffmpeg, or audacity can be used to record,
process and compress audio files.
<h2 id="recordmon">Recording a Monitor Mix of All Audio Playback</h2>
A monitoring stream records combined audio output from all playback devices,
allowing you to duplicate or save anything going through the audio subsystem.
This feature can be useful for screencasts or any kind of live audio mixing.
<p>
Create the monitor sub-device <code>mon</code> for
<a href="https://man.openbsd.org/sndiod">sndiod(8)</a> by using:
<pre class="cmdbox">
# <b>rcctl set sndiod flags -s default -m play,mon -s mon</b>
# <b>rcctl restart sndiod</b>
</pre>
Configure your program to record audio from the <code>snd/mon</code> device,
for instance:
<pre class="cmdbox">
$ <b>aucat -f snd/mon -o file.wav</b>
</pre>
At this point, whatever your system plays is recorded in <code>file.wav</code>.
<h2 id="audiolat">Lowering Audio Latency</h2>
<!-- This section Copyright (c) 2009 Alexandre Ratchov -->
Latency is the time between when a program takes the decision to play
a sample and when the user hears the sample.
Since audio data is always buffered, this delay is proportional to
the audio buffer size.
The following values are recommended:
<ul>
<li>Real-time synthesizers: 5ms.
This is the time it takes between hitting a key on your MIDI keyboard
and actually hearing the note.
Roughly, 5ms corresponds to the time it takes for the sound to
propagate 1.75m.
<li>Games: 50ms.
This is the time between when you see an event and you hear the
corresponding sound.
<li>Movie players and alike: 500ms and more.
Such applications "know" the sound to play in advance, and send audio
data in such a way that it is played simultaneously with the
corresponding picture.
</ul>
The smaller the audio buffers are (to achieve low latency), the larger the
probability to overrun/underrun is.
Buffer overruns/underruns result in stuttering of the sound.
<p>
sndiod(8) imposes a minimum latency on all audio applications,
and the default latency is 160ms.
If you plan to use applications that require a lower latency, use the
<code>-b</code> option to select the desired latency (expressed in number of
frames).
For instance, at 48000 samples/second, 50ms latency corresponds to:
<blockquote>
48000 samples/second × 0.050 seconds = 2400 samples
</blockquote>
Then do:
<pre class="cmdbox">
# <b>rcctl set sndiod flags -b2400</b>
</pre>
<h3>Does low latency improve audio-video synchronization?</h3>
No, synchronizing audio to video doesn't require low latency.
Synchronization problems are often caused by the software itself.
Forcing the application to use smaller buffers (by starting sndiod(8)
in low latency mode) may hide the actual problem in some cases, and
give the feeling that the software works better, but obviously the
right thing to do is to start searching for the corresponding bug.
<h2 id="audionet">Using Remote Audio Hardware</h2>
sndiod(8) can be configured to accept connections from the network,
allowing other machines to use the sound card as well.
On the remote system with the sound card, run:
<pre class="cmdbox">
# <b>rcctl set sndiod flags -L-</b>
</pre>
On the local system, configure your program to use <code>snd@hostname/0</code>,
where "hostname" is the address of the remote system.
The <code>AUDIODEVICE</code> environment variable could be set to the above
value to make the remote sound card the default audio device.
<p>
Any system able to connect to TCP port 11025 of the remote host will be able
to use the audio device.
For privacy reasons, only one user from one system may have connections
to it at a given time.
If multiple systems have to use the audio device simultaneously, the
sndio(7) authorization cookie must be the same.
For instance, copy your <code>~/.sndio/cookie</code> to all accounts
that may use the audio device.
<p>
To avoid glitches, TCP traffic on port 11025 could be prioritized with
the packet filter.
With the default configuration, sndiod will consume around 200kB/s of
network bandwidth.
<h2 id="default">Choosing the Default Audio Device</h2>
The default audio device is selected with the <code>AUDIODEVICE</code>
environment variable.
If it's not set, <code>snd/default</code> is used, which by default
points to the first audio device
managed by <a href="https://man.openbsd.org/sndiod">sndiod(8)</a>.
The most flexible way of choosing the default device is to export
<code>AUDIODEVICE</code>, possibly in the user's login profile.
<p>
Alternatively, <a href="https://man.openbsd.org/sndiod">sndiod(8)</a>'s
default device may be changed at runtime with the
<code>server.device</code> control exposed by
<a href="https://man.openbsd.org/sndioctl">sndioctl(1)</a>:
<pre class="cmdbox">
$ <b>sndioctl server.device=1</b>
</pre>
<p>
Another way to change the default audio output device is to make the desired
device the first device managed by
<a href="https://man.openbsd.org/sndiod">sndiod(8)</a>.
For example, to use an external DAC rather than your motherboard's onboard
audio, just change <a href="https://man.openbsd.org/sndiod">sndiod(8)</a>'s
startup flags to use that device:
<pre class="cmdbox">
# <b>rcctl set sndiod flags -f rsnd/1</b>
# <b>rcctl restart sndiod</b>
</pre>
This would make the second audio device (<code>rsnd/1</code>) the default.
<h2 id="audioprob">Debugging Audio Problems</h2>
If you do not hear anything when playing audio, it's possible there
is a mixer control turned to low or simply muted.
See <a href="#confaudio">this section</a> for configuring the mixer.
Please unmute <b>all</b> inputs and outputs before reporting a problem.
<p>
If you believe your device should be working, but for whatever reason isn't,
then it's time for a little debugging.
The following steps can determine if data is being processed by the DAC.
<pre class="cmdbox">
# <b>cat > /dev/audio0 < /dev/zero &</b>
[1] 9926
# <b>audioctl play.{bytes,errors}</b>
play.bytes=3312000
play.errors=0
# <b>audioctl play.{bytes,errors}</b>
play.bytes=7065600
play.errors=0
# <b>audioctl play.{bytes,errors}</b>
play.bytes=9379200
play.errors=0
# <b>kill %1</b>
# <b>fg %1</b>
cat > /dev/audio0 < /dev/zero
Terminated
</pre>
Here we see that the processed data count <code>play.bytes</code> increases
each time we check, so data is flowing.
We also see that the device has not underrun any samples
(<code>play.errors</code>).
That's good too.
<p>
Note that even if you had speakers plugged in when running the above
test, you should not have heard anything.
The test sends zeros to the device, which is silence for all currently
supported default encodings.
<p>
Since we know the device can process data, it's a good idea to check the mixer
settings again.
Make sure all outputs and all inputs are unmuted and are at a reasonable level.
<p>
If you are still having problems at this point, it's probably time to
<a href="../report.html">file a bug report</a>.
Besides the normal bug report information such as a full dmesg and description
of the problem, please also include the default output of
<code>mixerctl -v</code>
and the output of the above test for DAC processing.
<h2 id="midi">Using MIDI Instruments</h2>
The Musical Instrument Digital Interface (MIDI) protocol provides a
standardized and efficient means to represent musical performance information
as electronic data.
MIDI data contains only instructions needed by a synthesizer to play the
sounds, rather than the actual sounds.
<p>
To play MIDI data, a synthesizer connected to a MIDI port of the machine is
required.
Similarly, to record a MIDI data a MIDI instrument is required (such as a MIDI
keyboard).
Advanced MIDI instruments may contain multiple subparts (synthesizers,
keyboards, control surfaces, etc...).
They appear as multiple MIDI ports on OpenBSD.
<p>
When you already have OpenBSD running, look for MIDI ports in the output of
the dmesg(8) command.
An example of MIDI ports in a dmesg output is:
<pre class="cmdbox">
umidi0 at uhub2 port 2 configuration 1 interface 0 "Roland Roland XV-2020" rev 1.10/1.00 addr 2
midi0 at umidi0: <USB MIDI I/F>
umidi1 at uhub1 port 2 configuration 1 interface 1 "Evolution Electronics Ltd. USB Keystation 61es" rev 1.00/1.25 addr 3
midi1 at umidi1: <USB MIDI I/F>
</pre>
It shows two <a href="https://man.openbsd.org/midi">midi(4)</a> drivers
attached, known by programs as:
<ul>
<li><code>midi/0</code> - synthesizer connected via USB
<li><code>midi/1</code> - a MIDI master keyboard
</ul>
The output of the keyboard can be connected to the input of the synthesizer
as follows:
<pre class="cmdbox">
$ <b>midicat -q midi/0 -q midi/1</b>
</pre>
Now you can hear what you're playing on the MIDI keyboard on the synthesizer.
<p>
The <a href="https://man.openbsd.org/sndiod">sndiod(8)</a> server exposes MIDI
thru ports, allowing programs to send each other MIDI data.
For instance, if you have no hardware synthesizer connected, you could
start a software one (like the audio/fluidsynth port) and then use it as MIDI
output:
<pre class="cmdbox">
$ <b>midicat -q midi/0 -q midithru/0</b>
</pre>
<h2 id="webcam">Using a Webcam</h2>
<h3 id="enablevideo">Enabling Video Recording</h3>
For privacy reasons, video recording is disabled by default in OpenBSD.
The <code>kern.video.record</code> sysctl may be used to enable it.
<pre class="cmdbox">
# <b>sysctl kern.video.record=1</b>
# <b>echo kern.video.record=1 >> /etc/sysctl.conf</b>
</pre>
<h3>Supported Hardware</h3>
Many webcams following the USB Video Class (UVC) specification are supported
by the <a href="https://man.openbsd.org/uvideo">uvideo(4)</a> device driver
and are exposed to the user via the
<a href="https://man.openbsd.org/video.4">video(4)</a> layer.
<p>
A supported webcam (or other video device) shows up in <code>dmesg</code>
like this:
<pre class="cmdbox">
uvideo0 at uhub0 port 8 configuration 1 interface 0 "Azurewave Integrated Camera" rev 2.01/69.05 addr 10
video0 at uvideo0
uvideo1 at uhub0 port 8 configuration 1 interface 2 "Azurewave Integrated Camera" rev 2.01/69.05 addr 10
video1 at uvideo1
</pre>
This device will be accessible through <code>/dev/video0</code>.
<p>
Some laptops also attach a second (unusable) video device for the infrared
camera.
The usable camera device can be found with the
<a href="https://man.openbsd.org/video.1">video(1)</a> command:
<pre class="cmdbox">
$ <b>video -q -f /dev/video0</b>
video device /dev/video0:
encodings: yuy2
frame sizes (width x height, in pixels) and rates (in frames per second):
320x180: 30
320x240: 30
352x288: 30
424x240: 30
640x360: 30
640x480: 30
848x480: 20
960x540: 15
1280x720: 10
controls: brightness, contrast, saturation, hue, gamma, sharpness, white_balance_temperature
$ <b>video -q -f /dev/video1</b>
video: /dev/video1 has no usable YUV encodings
</pre>
Only root is allowed to access video devices by default.
The device's permissions must be changed to use it as a regular user:
<pre class="cmdbox">
# <b>chown $USER /dev/video0</b>
</pre>
<h3 id="recvideo">Recording a Webcam Stream</h3>
This section uses <code>ffplay</code> and <code>ffmpeg</code> from the
<code>graphics/ffmpeg</code> package.
To see the capabilities of a given camera, run the following:
<pre class="cmdbox">
$ <b>ffplay -f v4l2 -list_formats all -i /dev/video0</b>
[...]
[video4linux2,v4l2 @ 0x921f8420800] Raw : yuyv422 : YUYV : 640x480 320x180 320x240 352x288 424x240 640x360 848x480 960x540 1280x720
[video4linux2,v4l2 @ 0x921f8420800] Compressed: mjpeg : MJPEG : 1280x720 320x180 320x240 352x288 424x240 640x360 640x480 848x480 960x540
</pre>
The first line shows supported resolutions in the uncompressed YUYV format.
Frame rates in this format can be very low.
The second line shows the supported MJPEG compressed video resolutions,
which can deliver much higher frame rates.
<p>
Choose one of the MJPEG resolutions and run the following to test it:
<pre class="cmdbox">
$ <b>ffplay -f v4l2 -input_format mjpeg -video_size 1280x720 -i /dev/video0</b>
[...]
Input #0, video4linux2,v4l2, from '/dev/video0':B sq= 0B f=0/0
Duration: N/A, start: 1599377893.546533, bitrate: N/A
Stream #0:0: Video: mjpeg (Baseline), yuvj422p(pc, bt470bg/unknown/unknown), 1280x720, 30 fps, 30 tbr, 1000k tbn, 1000k tbc
</pre>
The webcam stream should be displayed along with the resolution and frame
rate.
<p>
If this works, video can be recorded with ffmpeg like so:
<pre class="cmdbox">
$ <b>ffmpeg -f v4l2 -input_format mjpeg -video_size 1280x720 -i /dev/video0 ~/video.mkv</b>
</pre>
Press "q" to end the recording.
<h3>Controlling Webcam Settings</h3>
Webcams usually have brightness, contrast and other controls that can be
altered with the
<a href="https://man.openbsd.org/video.1">video(1)</a> command.
<pre class="cmdbox">
$ <b>video -c</b>
brightness=128
contrast=32
saturation=64
hue=0
gamma=120
sharpness=3
white_balance_temperature=auto
</pre>
As an example, the brightness setting can be changed to 200:
<pre class="cmdbox">
$ <b>video brightness=200</b>
brightness: 128 -> 200
</pre>
All the settings can be reverted to their defaults with
<code>video -d</code>.
<p>
Some settings support automatic adjustments if set to a value of "auto."
<h3>Webcam Access in Web Browsers</h3>
Chromium has access to <code>/dev/video</code> by default.
To allow Chromium to access other video devices, the device paths must be
added to <code>/etc/chromium/unveil.main</code> and
<code>/etc/chromium/unveil.utility_video</code>.
<p>
Firefox has access to <code>/dev/video</code> and <code>/dev/video0</code>
by default.
To allow Firefox to access other video devices, the device paths must be
added to <code>/etc/firefox/unveil.main</code>.
<!-- XXX
To record MIDI files, you can use the <code>smfrec</code> utility bundled in
the <code>audio/midish</code> port.
For instance:
<pre class="cmdbox">
$ <b>smfrec -d rmidi/0 -i rmidi/1 file.mid</b>
</pre>
This will record what is played on the keyboard (<code>rmidi/1</code>) while
sending it in real-time on the synthesizer (<code>rmidi/0</code>) so you can
hear what you're playing.
More complicated operations like editing, routing, mixing and transforming
MIDI data can be achieved using the <code>rmidish</code> utility bundled in the
<code>audio/midish</code> port.
<h2 id="playDVD">Playing DVDs</h2>
OpenBSD supports DVD media through the ISO 9660 filesystem, which is also used
on CD-ROMs, and also through the
<a href="http://www.osta.org/specs/">Universal Disk Format (UDF)</a> filesystem
which is found on some DVDs.
However, almost all DVD-Video and DVD-ROM discs use the UDF bridge format,
which is a combination of the DVD MicroUDF (subset of UDF 1.02) and ISO 9660
filesystems.
It is used for backward compatibility reasons.
<p>
Some popular media players, supporting DVD playback, have been ported to
OpenBSD.
Please read the installation instructions that come with these packages,
because these tools may need further setup.
With these utilities, it is possible to play the DVDs by directly accessing
the raw device.
Of course, it is also possible to mount a DVD using
<a href="https://man.openbsd.org/mount_cd9660">mount_cd9660(8)</a> and play
the files directly.
<p>
<b>Notes:</b>
<ul>
<li>Nearly all DVDs you buy are encrypted using the Content Scrambling
System (CSS).
To be able to play these encrypted DVDs, you can use the <b>libdvd</b>
library, also available through packages and ports.
<li>Be aware that a region code may be present on your DVD disk(s).
This should not be much of a problem when playing DVDs on a computer.
</ul>
<h2 id="burnCD">Burning CDs and DVDs</h2>
<h3 id="burnIntro">Introduction and Basic Setup</h3>
You should first make sure your CD/DVD writer has been recognized and
configured by the kernel.
Most SCSI devices are supported.
SATA, IDE/ATAPI and USB devices are supported through SCSI emulation.
You can quickly find your device in the output of
<a href="https://man.openbsd.org/dmesg">dmesg(8)</a>.
Just look for lines beginning with "cd."
For example:
<pre class="cmdbox">
cd0 at scsibus0 targ 0 lun 0: <TOSHIBA, CD-ROM XM-5702B, 2826> SCSI0 5/cdrom removable
cd1 at scsibus1 targ 4 lun 0: <PLEXTOR, CD-R PX-R412C, 1.04> SCSI2 5/cdrom removable
</pre>
<h4>Error: <code>mount_cd9660: /dev/cd2c on /mnt/cdrom: No such file or directory</code></h4>
By default, the OpenBSD installer creates only two cd device nodes,
<code>cd0</code> and <code>cd1</code>.
To start using your <code>cd2</code> device, you must create the necessary
device nodes for it.
The recommended way to do that is using the
<a href="https://man.openbsd.org/MAKEDEV">MAKEDEV(8)</a> script.
<pre class="cmdbox">
# <b>cd /dev</b>
# <b>./MAKEDEV cd2</b>
</pre>
In what follows, we will mostly be accessing the CD/DVD writer through the
<i>raw</i> character device, <b>not</b> the <i>block</i> device.
<h4>Checking CD/DVD Writer Operation</h4>
It is recommended to check whether your CD/DVD writer is working correctly.
In this example, we'll be using this USB DVD writer:
<pre class="cmdbox">
cd2 at scsibus2 targ 1 lun 0: <LITE-ON, DVDRW LDW-851S, GS0C> SCSI0 5/cdrom removable
</pre>
Try to use it by mounting an existing CD/DVD in it.
If desired, you could also check the transfer rate you are getting when
copying files to your hard disk.
<h3 id="writeCD">Writing CDs</h3>
<h4>Creating Data CD-ROMs</h4>
First, you will want to create an ISO 9660 filesystem to put on a CD-ROM.
To do this you can use the
<a href="https://man.openbsd.org/mkhybrid">mkhybrid(8)</a>
utility in the base system, or the <code>mkisofs</code> utility from the
<code>cdrtools</code> <a href="faq15.html">package</a>.
In the examples below, we will use <code>mkhybrid</code>, although
<code>mkisofs</code> usage is very similar.
<p>
For example, to store the OpenBSD kernel sources in an ISO9660 image, you
might do:
<pre class="cmdbox">
$ <b>mkhybrid -R -o sys.iso /usr/src/sys</b>
Using ALTQ_RMC.000;1 for /usr/src/sys/altq/altq_rmclass_debug.h (altq_rmclass.h)
...
Using IEEE8021.00H;1 for /usr/src/sys/net80211/ieee80211_amrr.c (ieee80211.c)
10.89% done, estimate finish Sat Nov 3 08:01:23 2007
21.78% done, estimate finish Sat Nov 3 08:01:28 2007
...
87.12% done, estimate finish Sat Nov 3 08:01:31 2007
98.01% done, estimate finish Sat Nov 3 08:01:32 2007
Total translation table size: 0
Total rockridge attributes bytes: 896209
Total directory bytes: 2586624
Path table size(bytes): 11886
Max brk space used 0
45919 extents written (89 Mb)
</pre>
The <code>-R</code> option tells <code>mkhybrid</code> to create Rock Ridge
extensions in the ISO 9660 image.
The Rock Ridge Interchange Protocol was created to support POSIX filesystem
semantics in ISO 9660 filesystems, such as longer file names, ownerships,
permissions, file links, soft links, device nodes, deep file hierarchies
(more than 8 levels of subdirectories), etc.
<p>
If you want the long file names on your CD-ROM to be readable on Windows
systems, you should add the <code>-J</code> flag to include Joliet extensions
in the ISO 9660 image as well.
<p>
After creating the filesystem, you can verify it by
<a href="faq14.html#MountImage">mounting the ISO 9660 image</a>.
If all is well, you are now ready to burn the CD-R(W).
The easiest way to do this is to use the
<a href="https://man.openbsd.org/cdio">cdio(1)</a> utility.
<p>
If you are using multi-write media such as CD-RW, you will need to blank the
media before burning it.
<pre class="cmdbox">
# <b>cdio -f cd1c blank</b>
</pre>
You are now ready to burn the image created in the above example to a blank
CD-R(W).
You could use a command similar to:
<pre class="cmdbox">
# <b>cdio -f cd1c tao sys.iso</b>
</pre>
With the options specified above, we're asking cdio to use the second CD-ROM
device as the CD writer.
<p>
To verify whether the CD-ROM has been written correctly, you can mount it
and check whether everything is there.
To mount the filesystem, you should use the <i>block</i> device for the
CD-ROM drive, which in this case is still the CD writer:
<pre class="cmdbox">
# <b>mount /dev/cd1c /mnt/cdrom</b>
</pre>
<h4>Creating Audio CDs</h4>
To burn audio CDs, you can again use
<a href="https://man.openbsd.org/cdio">cdio(1)</a> with the <code>tao -a</code>
option.
<p>
As an example, we'll be making a backup copy of a music CD.
This involves two steps:
<ol>
<li>Fetch the audio tracks from the original CD.
<pre class="cmdbox">
# <b>cdio -f cd1c cdrip</b>
</pre>
This command will extract a series of WAV files from your second CD-ROM drive
to your disk.
<p>
<li>Write the audio tracks to a blank CD.
<pre class="cmdbox">
# <b>cdio -f cd1c tao -a *.wav</b>
</pre>
</ol>
<h3 id="writeDVD">Writing DVDs</h3>
There are a few important things about DVD you should know about before
proceeding to write your own DVDs.
<ul>
<li>If you really want to know all about DVDs, you can read the very
extensive <a href="https://www.dvddemystified.com/dvdfaq.html">DVD FAQ</a>
document to start with.
<li>This section has seen only very limited testing, and we certainly have
not tried every possible media and writer combination.
Nevertheless, we have had, or have heard of, positive experiences with
all of the DVD formats mentioned below.
</ul>
<h4>Different DVD Formats</h4>
There are a number of different DVD formats.
Commonly used are the DVD-R, DVD-RW, DVD+R, and DVD+RW formats (R means
writable once, RW means it can be rewritten a few thousand times).
They are pretty much competing standards.
<p>
A pretty different format is DVD-RAM, which was mainly developed as a
data drive and has advanced packet writing functions, allowing it to be
used like a kind of optical hard disk.
DVD-RAM is not recommended for video usage as video gets written to the
discs in a format not compatible with normal DVD players.
<p>
The important thing is using media which suits your DVD writer.
If you expect compatibility with other DVD players, watch your step and
be sure to read
<a href="https://www.dvddemystified.com/dvdfaq.html#4.3.1">this section</a>
of the DVD FAQ.
<h4>DVD Writing Speed</h4>
It may be useful to point out that DVD speed indications differ from CD-ROM
speed indications.
The following table gives an overview:
<table>
<tr>
<td>DVD read/write speed
<td>Transfer rate (MB/s)
<td>Equivalent CD-R(W) read/write speed
<tr>
<td>1×
<td>1.32
<td>9×
<tr>
<td>2×
<td>2.64
<td>18×
<tr>
<td>4×
<td>5.28
<td>36×
<tr>
<td>8×
<td>10.57
<td>72×
</table>
<p>
As can been seen from the table, the transfer rates are relatively high,
and you should check whether your bus (SCSI, IDE/ATAPI, SATA, USB) is
performant enough to handle this throughput.
In general, the speed of SCSI, SATA, and IDE/ATAPI buses should be just fine.
<h4>Writing the DVD</h4>
Basically, the process is very similar to writing CD-R(W)s.
The software used, however, is different.
At the moment, the best option is <code>growisofs</code> from the
<code>sysutils/dvd+rw-tools</code> package.
This utility writes an ISO 9660 image to the DVD medium.
All recordable DVD formats are supported by the dvd+rw-tools.
<p>
In case you want to find out more info about the media in your DVD writer,
you can use the <code>dvd+rw-tools</code> utility.
There are two options to write the DVD:
<ul>
<li>Pre-master an ISO 9660 from your data, storing the image on your hard
disk, then write this image to the DVD.
<li>Write an ISO 9660 from your data immediately to the DVD.
</ul>
I created a pre-mastered ISO 9660 image from the OpenBSD CVS modules
(src, xenocara, ports and www) contained in the /cvs directory on my disk.
I used the following command, which looks very similar to the one I used
to create the CD-ROM image above.
<pre class="cmdbox">
$ <b>mkhybrid -r -o cvs.iso /cvs</b>
</pre>
If desired, check the ISO 9660 filesystem by
<a href="faq14.html#MountImage">mounting the image</a>.
To write this image (about 2 GB) to an empty DVD disc, one could use:
<pre class="cmdbox">
# <b>growisofs -dvd-compat -Z /dev/rcd2c=cvs.iso</b>
Executing 'builtin_dd if=cvs.iso of=/dev/rcd2c obs=32k seek=0'
/dev/rcd2c: pre-formatting blank DVD+RW...
/dev/rcd2c: "Current Write Speed" is 4.1x1385KBps.
23822336/1545832448 ( 1.5%) @3.9x, remaining 5:19
42172416/1545832448 ( 2.7%) @3.9x, remaining 5:20
60522496/1545832448 ( 3.9%) @3.9x, remaining 4:54
...
1504706560/1545832448 (97.3%) @3.9x, remaining 0:07
1523318784/1545832448 (98.5%) @3.9x, remaining 0:04
1541898240/1545832448 (99.7%) @3.9x, remaining 0:00
/dev/rcd2c: flushing cache
/dev/rcd2c: writing lead-out
/dev/rcd2c: reloading tray
</pre>
The <code>-Z</code> option tells growisofs to burn an initial session to the
device, which in this case is my DVD writer, attached to <code>cd2</code>.
The <code>-dvd-compat</code> option closes the disk, which means no more
sessions can be appended to it.
This should provide better compatibility with video DVD players and some
older DVD-ROM units.
<p>
Notice how growisofs indicates the writing speed, in this case 3.9x
DVD speed, which is what could be expected from the media and writer
combination, as indicated by <code>dvd+rw-tools</code>.
<p>
If you are short on disk space and cannot store an ISO 9660 image for a
DVD, you can write your data directly to the DVD.
Let's first do a dry run, which simulates the creation of the filesystem.
<pre class="cmdbox">
# <b>growisofs -dry-run -Z /dev/rcd2c -R /cvs</b>
</pre>
If this succeeds, just leave out the -dry-run option and start burning the
DVD.
<p>
It is also possible to append data to an existing DVD, by using the
<code>-M</code> option, which merges a new session to an existing one:
<pre class="cmdbox">
# <b>growisofs -M /dev/rcd2c -R /mydata</b>
</pre>
For more information about growisofs, refer to the man page.
<p>
When you have finished writing the DVD, mount it and check whether
everything you expected to be there is indeed there.
<h4>Why am I not getting the writing speed I expected?</h4>
Instead of the above writing output, you may see something like:
<pre class="cmdbox">
4784128/1545832448 ( 0.3%) @0.7x, remaining 26:50
7929856/1545832448 ( 0.5%) @0.7x, remaining 29:05
14123008/1545832448 ( 0.9%) @0.7x, remaining 27:06
...
</pre>
which is much slower.
It means you are somehow not getting enough throughput on whatever bus
your DVD writer is using.
In the above example, the USB DVD writer was attached to a machine on which
the <a href="https://man.openbsd.org/ehci">ehci(4)</a> driver, used by USB 2.0
controllers, failed to initialize properly.
As always, you are welcome to provide patches and test results.
The DVD writer fell back to the slower USB 1.1 interface, which causes
reduced throughput.
Indeed, USB 1.1 is limited to 12 Mbit/s, which amounts to 1.43 MB/s or 1.08x
in DVD speed terms.
The DVD writer falls back to a lower pace than the maximum to reduce the risk
of buffer underruns.
<h2 id="plugins">Browser Plugins (Java and Flash)</h2>
Java plugin support can be obtained with the <code>icedtea-web</code> package.
In your browser, check for the list of detected plugins and ensure icedtea-web
is there.
This is usually found via <code>about:plugins</code> in Mozilla browsers and
<code>chrome://components</code> in Chromium/Iridium.
<p>
Note that due to the security issues with Java applets on the web, most
browsers disable Java support by default.
You will be prompted for your explicit consent to run applets via icedtea-web.
<p>
Adobe's Flash plugin is distributed in binary form only, and they do not
provide a native OpenBSD version.
Considering their security record, we thank them for this neglect.
<p>
If you are just looking to watch Flash videos from common websites,
there are a number of options in packages, including
<a href="https://github.com/monsieurvideo/get-flash-videos">get_flash_videos</a>,
<a href="https://flavio.tordini.org/minitube">minitube</a>,
<a href="https://streamlink.github.io/">streamlink</a>
and <a href="https://rg3.github.io/youtube-dl/">youtube-dl</a>.
XXX -->
![[BACK]](/icons/back.gif){kind=icon}
Return to faq13.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / www / faq