https://wiki.xiph.org/api.php?action=feedcontributions&user=Xiphmont&feedformat=atomXiphWiki - User contributions [en]2024-03-29T01:07:58ZUser contributionsMediaWiki 1.40.1https://wiki.xiph.org/index.php?title=TDLT&diff=14208TDLT2013-06-20T03:11:36Z<p>Xiphmont: Explicitly state the implicit AR95 assumption</p>
<hr />
<div>This page holds the results of Time Domain Lapped Transform (TDLT) optimization problems looking for integer transform coefficients that provide optimal coding gain. All numbers are generated against AR95 unless otherwise stated. Wherever possible the assumptions are stated. Later we should include testing against actual image data to verify the results (see test data [http://people.xiph.org/~tterribe/tmp/subset1-y4m.tar.gz here]).<br />
<br />
The coding gain objective used as the objective is taken from slide 13 of Tim's presentation [http://people.xiph.org/~tterribe/pubs/lca2012/auckland/intro_to_video1.pdf An Introduction to Video Coding]<br />
<br />
<need figure with block matrix diagrams><br />
<br />
The free parameters are initially just the coefficients p_0,...,p_m,q_0,...,q_m where m=(n/2)-1. We limit these to being dyadic rationals, e.g., x/2^d with d=6, between [-1,1].<br />
<br />
Given p's and q's and assuming a linear ramp constrains the s's.<br />
<br />
== 4x8 ==<br />
<br />
Optimal real-valued coefficients for V:<br />
<br />
p0 = -0.18117338915051454<br />
<br />
q0 = 0.6331818230771687<br />
<br />
CG = 8.60603<br />
<br />
{|<br />
!<br />
!p0<br />
!q0<br />
!s0<br />
!s1<br />
!CG<br />
!SBA<br />
!Filterbank<br />
|-<br />
|R=f<br>6-bit<br />
| -11/64<br>-0.171875<br />
| 36/64<br>0.5625<br />
| 91/64<br>1.421875<br />
| 85/64<br>1.328125<br />
| &nbsp;<br>8.63473<br />
| &nbsp;<br>22.0331<br />
| [[Image:4x8.png|64px]]<br />
|-<br />
|R=f<br>5-bit<br />
| -5/32<br>-0.15625<br />
| 18/32<br>0.5625<br />
| 46/32<br>1.4375<br />
| 42/32<br>1.3125<br />
| &nbsp;<br>8.63409<br />
| &nbsp;<br>22.5715<br />
| [[Image:4x8_5bit.png|64px]]<br />
|-<br />
|R=t,D=f<br />
| -12/64<br>-0.1875<br />
| 41/64<br>0.640625<br />
| 92/64<br>1.4375<br />
| 1093/768<br>1.423177<br />
| &nbsp;<br>8.60486<br />
| &nbsp;<br>20.0573<br />
| [[Image:4x8r.png|64px]]<br />
|-<br />
|R=t,D=t<br>8-bit<br />
| -32/256<br>-0.125<br />
| 162/256<br>0.6328125<br />
| 376/256<br>1.46875<br />
| 357/256<br>1.39453125<br />
| &nbsp;<br>8.60104<br />
| &nbsp;<br>21.4037<br />
| [[Image:4x8rd_8bit.png|64px]]<br />
|-<br />
|R=t,D=t<br>7-bit<br />
| -32/128<br>-0.25<br />
| 82/128<br>0.640625<br />
| 184/128<br>1.4375<br />
| 186/128<br>1.453125<br />
| &nbsp;<br>8.59886<br />
| &nbsp;<br>18.9411<br />
| [[Image:4x8rd_7bit.png|64px]]<br />
|-<br />
|R=t,D=t<br>6-bit<br />
| -16/64<br>-0.25<br />
| 41/64<br>0.640625<br />
| 92/64<br>1.4375<br />
| 93/64<br>1.453125<br />
| &nbsp;<br>8.59886<br />
| &nbsp;<br>18.9411<br />
| [[Image:4x8rd.png|64px]]<br />
|-<br />
|R=t,D=t<br>5-bit<br />
| -8/32<br>-0.25<br />
| 19/32<br>0.59375<br />
| 52/32<br>1.625<br />
| 47/32<br>1.46875<br />
| &nbsp;<br>8.56068<br />
| &nbsp;<br>20.3279<br />
| [[Image:4x8rd_5bit.png|64px]]<br />
|-<br />
|R=t,D=t<br>max SBA<br />
| -8/64<br>-0.125<br />
| 30/64<br>0.46875<br />
| 136/64<br>2.125<br />
| 91/64<br>1.421875<br />
| &nbsp;<br>8.23230<br />
| &nbsp;<br>25.1934<br />
| [[Image:4x8rd_sba.png|64px]]<br />
|}<br />
<br />
== 8x16 ==<br />
<br />
Optimal real-valued coefficients for V:<br />
<br />
p0 = -0.39460731547057293<br />
<br />
p1 = -0.33002212811740816<br />
<br />
p2 = -0.12391270981321137<br />
<br />
q0 = 0.822154737511288<br />
<br />
q1 = 0.632488694485779<br />
<br />
q2 = 0.40214668677553894<br />
<br />
CG = 9.56867<br />
<br />
{|<br />
!<br />
!p0<br />
!p1<br />
!p2<br />
!q0<br />
!q1<br />
!q2<br />
!s0<br />
!s1<br />
!s2<br />
!s3<br />
!CG<br />
!Filterbank<br />
|-<br />
|R=f<br>6-bit<br />
| -23/64<br>-0.359375<br />
| -18/64<br>-0.28125<br />
| -6/64<br>-0.09375<br />
| 48/64<br>0.75<br />
| 34/64<br>0.53125<br />
| 20/64<br>0.3125<br />
| 90/64<br>1.40625<br />
| 73/64<br>1.140625<br />
| 72/64<br>1.125<br />
| 75/64<br>1.171875<br />
| &nbsp;<br>9.60021<br />
| [[Image:8x16.png|64px]]<br />
|-<br />
|R=f<br>5-bit<br />
| -12/32<br>-0.375<br />
| -9/32<br>-0.28125<br />
| -4/32<br>-0.125<br />
| 24/32<br>0.75<br />
| 17/32<br>0.53125<br />
| 10/32<br><br />
| 45/32<br>1.40625<br />
| 37/32<br>1.15625<br />
| 36/32<br><br />
| 38/32<br>1.1875<br />
| &nbsp;<br>9.59946<br />
| [[Image:8x16_5bit.png|64px]]<br />
|-<br />
|R=t,D=f<br />
| -26/64<br>-0.40625<br />
| -22/64<br>-0.34375<br />
| -8/64<br>-0.125<br />
| 53/64<br>0.828125<br />
| 41/64<br>0.640625<br />
| 26/64<br>0.40625<br />
| 11/8<br>1.375<br />
| 879/768<br>1.14453125<br />
| 1469/1280<br>1.14765625<br />
| 275/224<br>1.2276785714285714<br />
| &nbsp;<br>9.56627<br />
| [[Image:8x16r.png|64px]]<br />
|-<br />
|R=t,D=t<br>8-bit<br />
| -96/256<br>-0.375<br />
| -83/256<br>-0.32421875<br />
| -36/256<br>-0.140625<br />
| 210/256<br>0.8203125<br />
| 160/256<br>0.625<br />
| 104/256<br>0.40625<br />
| 368/256<br>1.4375<br />
| 302/256<br>1.1796875<br />
| 293/256<br>1.14453125<br />
| 317/256<br>1.23828125<br />
| &nbsp;<br>9.56761<br />
| [[Image:8x16rd_8bit.png|64px]]<br />
|-<br />
|R=t,D=t<br>7-bit<br />
| -48/128<br>-0.375<br />
| -45/128<br>-0.3515625<br />
| -16/128<br>-0.125<br />
| 105/128<br>0.8203125<br />
| 80/128<br>0.625<br />
| 53/128<br>0.4140625<br />
| 184/128<br>1.4375<br />
| 151/128<br>1.1796875<br />
| 147/128<br>1.1484375<br />
| 157/128<br>1.2265625<br />
| &nbsp;<br>9.56672<br />
| [[Image:8x16rd_7bit.png|64px]]<br />
|-<br />
|R=t,D=t<br>6-bit<br />
| -24/64<br>-0.375<br />
| -20/64<br>-0.3125<br />
| -4/64<br>-0.0625<br />
| 53/64<br>0.828125<br />
| 40/64<br>0.625<br />
| 24/64<br>0.375<br />
| 88/64<br>1.375<br />
| 75/64<br>1.171875<br />
| 76/64<br>1.1875<br />
| 76/64<br>1.1875<br />
| &nbsp;<br>9.56161<br />
| [[Image:8x16rd.png|64px]]<br />
|-<br />
|R=t,D=t<br>5-bit<br />
| -12/32<br>-0.375<br />
| -10/32<br>-0.3125<br />
| -2/32<br>-0.0625<br />
| 26/32<br>0.8125<br />
| 20/32<br>0.625<br />
| 12/32<br>0.375<br />
| 48/32<br>1.5<br />
| 38/32<br>1.1875<br />
| 38/32<br>1.1875<br />
| 38/32<br>1.1875<br />
| &nbsp;<br>9.5596<br />
| [[Image:8x16rd_5bit.png|64px]]<br />
|}<br />
<br />
== 16x32 ==<br />
<br />
Best-known real-valued coefficients for V (R=t):<br />
<br />
p0 = -0.42111473798940136<br />
<br />
p1 = -0.4121736499899753<br />
<br />
p2 = -0.3350240707669929<br />
<br />
p3 = -0.3224547931861314<br />
<br />
p4 = -0.25883387978005545<br />
<br />
p5 = -0.20951913473498104<br />
<br />
p6 = -0.0598657149803332<br />
<br />
q0 = 0.9107782439906195<br />
<br />
q1 = 0.8109855829278226<br />
<br />
q2 = 0.715846584586721<br />
<br />
q3 = 0.6135951570714172<br />
<br />
q4 = 0.49846644853347627<br />
<br />
q5 = 0.3945215834922529<br />
<br />
q6 = 0.21822275136248082<br />
<br />
CG = 9.81157<br />
<br />
{|<br />
!<br />
!p0<br />
!p1<br />
!p2<br />
!p3<br />
!p4<br />
!p5<br />
!p6<br />
!q0<br />
!q1<br />
!q2<br />
!q3<br />
!q4<br />
!q5<br />
!q6<br />
!s0<br />
!s1<br />
!s2<br />
!s3<br />
!s4<br />
!s5<br />
!s6<br />
!s7<br />
!CG<br />
!Filterbank<br />
|-<br />
|R=f<br>6-bit<br />
| -24/64<br>-0.375<br />
| -23/64<br>-0.359375<br />
| -17/64<br>-0.265625<br />
| -12/64<br>-0.1875<br />
| -14/64<br>-0.21875<br />
| -13/64<br>-0.203125<br />
| -7/64<br>-0.109375<br />
| 50/64<br>0.78125<br />
| 40/64<br>0.625<br />
| 31/64<br>0.484375<br />
| 22/64<br>0.34375<br />
| 18/64<br>0.28125<br />
| 16/64<br>0.25<br />
| 11/64<br>0.171875<br />
| 90/64<br>1.40625<br />
| 74/64<br>1.15625<br />
| 73/64<br>1.140625<br />
| 71/64<br>1.109375<br />
| 67/64<br>1.046875<br />
| 67/64<br>1.046875<br />
| 67/64<br>1.046875<br />
| 72/64<br>1.125<br />
| &nbsp;<br>9.89338<br />
| [[Image:16x32.png|64px]]<br />
|-<br />
|R=t,D=f<br />
| -26/64<br>-0.40625<br />
| -27/64<br>-0.421875<br />
| -22/64<br>-0.34375<br />
| -18/64<br>-0.28125<br />
| -16/64<br>-0.25<br />
| -14/64<br>-0.21875<br />
| -5/64<br>-0.078125<br />
| 58/64<br>0.90625<br />
| 52/64<br>0.8125<br />
| 45/64<br>0.703125<br />
| 36/64<br>0.5625<br />
| 31/64<br>0.484375<br />
| 23/64<br>0.359375<br />
| 13/64<br>0.203125<br />
| 3/2<br>1.5<br />
| 77/64<br>1.203125<br />
| 77/64<br>1.203125<br />
| 1105/896<br>1.23326<br />
| 218/192<br>1.135417<br />
| 197/176<br>1.119318<br />
| 1919/1664<br>1.153245<br />
| 4351/3840<br>1.133073<br />
| &nbsp;<br>9.79398<br />
| [[Image:16x32r.png|64px]]<br />
|-<br />
|R=t,D=t<br>6-bit<br />
| -32/64<br>-0.5<br />
| -28/64<br>-0.4375<br />
| -24/64<br>-0.375<br />
| -32/64<br>-0.5<br />
| -24/64<br>-0.375<br />
| -13/64<br>-0.203125<br />
| -2/64<br>-0.03125<br />
| 59/64<br>0.921875<br />
| 53/64<br>0.828125<br />
| 46/64<br>0.71875<br />
| 41/64<br>0.640625<br />
| 35/64<br>0.546875<br />
| 24/64<br>0.375<br />
| 12/64<br>0.1875<br />
| 80/64<br>1.25<br />
| 72/64<br>1.125<br />
| 73/64<br>1.140625<br />
| 68/64<br>1.0625<br />
| 72/64<br>1.125<br />
| 74/64<br>1.15625<br />
| 74/64<br>1.15625<br />
| 70/64<br>1.09375<br />
| &nbsp;<br>9.78294<br />
| [[Image:16x32rd.png|64px]]<br />
|}<br />
<br />
== Type-IV Coding Gain ==<br />
<br />
{|<br />
!<br />
!4x8<br />
!4x8 Ramp<br />
!8x16<br />
!8x16 Ramp<br />
!16x32<br />
!16x32 Ramp<br />
|-<br />
|Real Valued<br />
|8.6349<br />
|8.60603<br />
|9.6005<br />
|9.56867<br />
|9.9057<br />
|9.81157<br />
|-<br />
|Dyadic (8-bit)<br />
|<br />
|8.60104<br />
|<br />
|9.56761<br />
|<br />
|<br />
|-<br />
|Loss<br />
|<br />
|0.00499<br />
|<br />
|0.00105<br />
|<br />
|<br />
|-<br />
|Dyadic (7-bit)<br />
|<br />
|8.59886<br />
|<br />
|9.56672<br />
|<br />
|<br />
|-<br />
|Loss<br />
|<br />
|0.00717<br />
|<br />
|0.00195<br />
|<br />
|<br />
|-<br />
|Dyadic (6-bit)<br />
|8.63473<br />
|8.59886<br />
|9.60021<br />
|9.56161<br />
|9.89338<br />
|9.78294<br />
|-<br />
|Loss<br />
|0.00017<br />
|0.00717<br />
|0.00029<br />
|0.00706<br />
|0.01232<br />
|0.02863<br />
|-<br />
|Dyadic (5-bit)<br />
|8.63409<br />
|8.56068<br />
|9.59946<br />
|9.5596<br />
|<br />
|<br />
|-<br />
|Loss<br />
|0.00081<br />
|0.04535<br />
|0.00104<br />
|0.00907<br />
|<br />
|<br />
|}<br />
<br />
== 8x16 Type-III ==<br />
<br />
{|<br />
!<br />
!p0<br />
!p1<br />
!p2<br />
!q0<br />
!q1<br />
!q2<br />
!s0<br />
!s1<br />
!s2<br />
!s3<br />
!CG<br />
!Filterbank<br />
|-<br />
|R=f<br>6-bit<br />
| -25/64<br>-0.390625<br />
| -20/64<br>-0.3125<br />
| -7/64<br>-0.109375<br />
| 49/64<br>0.765625<br />
| 35/64<br>0.546875<br />
| 21/64<br>0.328125<br />
| 90/64<br>1.40625<br />
| 72/64<br>1.125<br />
| 73/64<br>1.140625<br />
| 76/64<br>1.1875<br />
| &nbsp;<br>9.6112<br />
| [[Image:8x16_type3.png|64px]]<br />
|-<br />
|R=f<br>5-bit<br />
| -13/32<br>-0.40625<br />
| -11/32<br>-0.34375<br />
| -4/32<br>-0.125<br />
| 25/32<br>0.78125<br />
| 18/32<br>0.5625<br />
| 11/32<br>0.34375<br />
| 45/32<br>1.40625<br />
| 36/32<br>1.125<br />
| 36/32<br>1.125<br />
| 38/32<br>1.1875<br />
| &nbsp;<br>9.61048<br />
| [[Image:8x16_type3_5bit.png|64px]]<br />
|}<br />
<br />
== 16x32 Type-III ==<br />
<br />
{|<br />
!<br />
!p0<br />
!p1<br />
!p2<br />
!p3<br />
!p4<br />
!p5<br />
!p6<br />
!q0<br />
!q1<br />
!q2<br />
!q3<br />
!q4<br />
!q5<br />
!q6<br />
!s0<br />
!s1<br />
!s2<br />
!s3<br />
!s4<br />
!s5<br />
!s6<br />
!s7<br />
!CG<br />
!Filterbank<br />
|-<br />
|R=f<br>6-bit<br />
| -30/64<br>-0.46875<br />
| -35/64<br>-0.546875<br />
| -31/64<br>-0.484375<br />
| -29/64<br>-0.453125<br />
| -25/64<br>-0.390625<br />
| -19/64<br>-0.296875<br />
| -10/64<br>-0.15625<br />
| 54/64<br>0.84375<br />
| 45/64<br>0.703125<br />
| 40/64<br>0.625<br />
| 36/64<br>0.5625<br />
| 32/64<br>0.5<br />
| 25/64<br>0.390625<br />
| 17/64<br>0.265625<br />
| 90/64<br>1.40625<br />
| 70/64<br>1.09375<br />
| 69/64<br>1.078125<br />
| 67/64<br>1.046875<br />
| 67/64<br>1.046875<br />
| 67/64<br>1.046875<br />
| 68/64<br>1.0625<br />
| 74/64<br>1.15625<br />
| &nbsp;<br>9.94127<br />
| [[Image:16x32_type3_6bit.png|64px]]<br />
|-<br />
|R=f<br>5-bit<br />
| -15/32<br>-0.46875<br />
| -17/32<br>-0.53125<br />
| -14/32<br>-0.4375<br />
| -12/32<br>-0.375<br />
| -9/32<br>-0.28125<br />
| -5/32<br>-0.15625<br />
| 0/32<br>0.0<br />
| 27/32<br>0.84375<br />
| 23/32<br>0.71875<br />
| 20/32<br>0.625<br />
| 17/32<br>0.53125<br />
| 14/32<br>0.4375<br />
| 9/32<br>0.28125<br />
| 3/32<br>0.09375<br />
| 45/32<br>1.40625<br />
| 35/32<br>1.09375<br />
| 35/32<br>1.09375<br />
| 34/32<br>1.0625<br />
| 34/32<br>1.0625<br />
| 35/32<br>1.09375<br />
| 36/32<br>1.125<br />
| 33/32<br>1.03125<br />
| &nbsp;<br>9.93998<br />
| [[Image:16x32_type3_5bit.png|64px]]<br />
|}<br />
<br />
== Type-III Coding Gain ==<br />
<br />
{|<br />
!<br />
!4x8<br />
!8x16<br />
!16x32<br />
|-<br />
|Real Valued<br />
|8.6349<br />
|9.6115<br />
|9.9496<br />
|-<br />
|Dyadic (6-bit)<br />
|8.63473<br />
|9.6112<br />
|9.94127<br />
|-<br />
|Loss<br />
|0.00017<br />
|0.00030<br />
|0.00833<br />
|-<br />
|Dyadic (5-bit)<br />
|8.63409<br />
|9.61048<br />
|9.93998<br />
|-<br />
|Loss<br />
|0.00081<br />
|0.00102<br />
|0.00962<br />
|}<br />
<br />
== Simplex search results ==<br />
<br />
=== Type-IV ===<br />
* 8x16 2D AR95<br />
** 19.199865874793673 { 89, 73, 72, 75,-23,-18, -6, 48, 34, 20}<br />
* 8x16 Subset 1<br />
** 13.9812271938690706 { 84, 68, 67, 68,-24,-19, -8, 38, 24, 13}<br />
* 8x16 Subset 3<br />
** 16.7631044694739657 { 85, 68, 67, 69,-24,-18, -9, 38, 24, 13}<br />
<br />
=== Type-III ===<br />
* 8x16 2D AR95<br />
** 19.2223200050370124 { 90, 72, 73, 76,-25,-20, -7, 49, 35, 21}<br />
* 8x16 Subset 1<br />
** 14.0121200303196343 { 86, 66, 67, 69,-28,-25,-11, 44, 28, 16}<br />
* 8x16 Subset 3<br />
** 16.8035257369844686 { 87, 66, 67, 70,-29,-24,-11, 44, 28, 15}</div>Xiphmonthttps://wiki.xiph.org/index.php?title=Talk:Videos/Digital_Show_and_Tell&diff=14190Talk:Videos/Digital Show and Tell2013-06-15T03:45:44Z<p>Xiphmont: answer Stuarticus</p>
<hr />
<div>Greetings, Feel free to comment here— just log in to edit— or join us on [http://webchat.freenode.net/?channels=xiph IRC chat]. <br />
<br />
The wiki version of the video isn't yet as complete as the last video, due to schedules and timelines. In particular I think it could use some more going-deeper coverage. I'm surprised that I couldn't better HTML5 audio api examples of the "type your own JS, get audio and a scope" kind, if anyone knows of a better one than the one we have now that would be great.<br />
<br />
--[[User:Gmaxwell|Gmaxwell]] 02:54, 26 February 2013 (PST)<br />
<br />
Just dropping a line to say thank you! I'm continually impressed by the guides and overall outreach coming out of the xiph team. The latest video was a great introduction that managed to walk that fine line between theory and application without falling over or flailing about madly (in my opinion, anyway). Not to mention, I'm going through the gtk-bounce and waveform code now and really like it! It's not so trivial a piece of software as to be meaningless when learning to code useful applications, but it's not so gigantic as to be unapproachable either. Hell, I think it would serve as a great example for the GNOME folks to use in their documentation. Most guides on GTK just have you draw shapes on the screen and leave it at that. All in all, I'm really impressed and hope to have a similar setup replicated in a few weeks at my university, just for the sake of it.<br />
<br />
--[[User:Aggroskater|Aggroskater]] 23:16, 26 February 2013 (PST)<br />
<br />
: Some parts are better written than others... I used enough cut & paste to warn against taking it too seriously :-) --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
@Monty: Thanks for these information. And as a non-native English speaker I want to thank you for your clear pronunciation.<br />
What did you mean with "no one ever ruined a great recording by not dithering the final master."? Do you mean, that nobody ever would forget it, or that it was not ruinous?<br />
That "CSS is awesome"-cup made me really nervous. I hope it means something like "Cascading Style Sheets", and not, what would fit better in this context, "Content Scramble System"[shudder]!<br />
--[[User:Akf|Akf]] 15:20, 27 February 2013 (PST)<br />
<br />
: I meant that "not adding dither is not ruinous". I recall in at least one listening test on the subject, a minority of participants had a statistically significant preference for undithered versions, at least on those samples where it was in fact audible and the testers were encouraged to increase gain and listen to fade-outs. *However* I can't find the results of that test now that I've gone back to look for it, so my memory may be faulty. I've asked the HA folks to help me find it again if it really existed :-) <br />
:CSS refers to [[WikiPedia:Cascading Style Sheets|Cascading Style Sheets]]. Thus the typsetting that overflows the box. --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
: I once built an 8-bit ADC from transistors, for experimentation. One strange result was how few bits are needed for speech. 8kHz with just one bit resolution is still quite intelligible (though rather noisy). --[[User:RichardNeill|RichardNeill]] 08:08, 4 March 2013 (PST)<br />
<br />
Thanks for these resources! One question: In the vid, you mention the Gibbs phenomenon. Is that in any way related to the Fourier uncertainty principle? These days, in various audio-related forums, people throw this Oppenheim and Magnasco (2013) paper entitled "Human hearing beats the Fourier uncertainty principle" around in response to your 24/192 article. Does the paper qualify any of the results presented in the video and/or your 24/192 article? (Just fixed the reference.) [[User:Lenfaki|Lenfaki]] 13:14, 28 February 2013 (PST)<br />
<br />
: it is related to the fourier uncertainty principle in that all of these effects are in some way related by the same math. As for the "Human hearing beats the Fourier uncertainty principle" paper floating around, a) the headline is effectively wrong, b) the effect described as 'newly discovered' has been understood for roughly 100 years, this merely adds some new hard measurements to the data set, c) the Gabor limit does not even apply to the detection task they're describing. So either the authors or their editor are partly confused. [http://www.hydrogenaudio.org/forums/index.php?showtopic=99371| There's been a decent discussion of it at Hydrogen Audio], with none other than James Johnston and Ethan Winer weighing in. --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
<br />
You talk about discrete values (whether the analog sample points, or the infinitesimal image pixels). BUT, these are in some way, averages. In a digital camera, the pixel value is the integral across about 90% of the pixel-pitch. In analog audio, is it an instantaneous sample, or an average over the preceding sample-interval, or is it sometimes even more "blurred" than that? Also, when performing DAC, how do we get rid of the stairstep so perfectly without distortion? --[[User:RichardNeill|RichardNeill]] 07:51, 4 March 2013 (PST)<br />
<br />
: The pixel values in a camera are area averages exactly as you say, a necessary compromise in order to have enough light to work with. The sensor sits behind an optical lowpass filter that is intentionally blurring the image to prevent much of the aliasing distortion (Moiré) that would otherwise occur. Despite that, cameras still alias a bit, and if you _remove_ that anti-aliasing filter, you get much more (I have such a camera, danged filter was bonded to the hot filter, so both had to go to photograph hydrogen alpha lines).<br />
<br />
: Audio does in fact use as close to an instantaneous sample as possible. The 'stairsteps' of a zero-order hold are quite regular in the frequency domain; they're folded mirror images of the original spectrum extending to infinity. All the anti-imaging filter has to do is cut off everything above the original channel bandwidth, and it doesn't even have to do a great job to beat a human ear :-) --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
What's the correct way to plot a reconstructed waveform? If I have an array of samples and play them back through a DAC, the oscilloscope shows a smooth curve. But plotting them with eg matplotlib shows a stairstep. Thanks --[[User:RichardNeill|RichardNeill]] 07:58, 4 March 2013 (PST)<br />
<br />
: well, a fully reconstructed waveform is equal to the original input; it's a smooth continuous waveform. OTOH, if you want to plot an actual zero-order hold, a zero order hold really is a staircase waveform.<br />
<br />
: If you want to plot the digital waveform pre-reconstruction, a mathemetician would always use lollipops, an engineer will use whatever's the most convenient. --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
<br />
I have a strange issue with the gtk-bounce program - on (k)ubuntu 12.10, spectrum and waveform work just fine, but if I scroll into the gtk-bounce panel, the cursor disappears. Anyone seen that behaviour? - Julf<br />
<br />
: Edit out the calls to "hide_mouse()" in gtk-bounce-widget.c. It's hiding the mouse on purpose because it's supposedly a touch application :-) --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
One issue I'm not sure you have covered, relates content with short, loud sections (e.g. more like a movie or maybe classical music, less like pop music). <br />
I understand that that a 10dB change in sound level is perceived as twice as loud. <br />
Lets say we have some content where one section is 4 times (20dB) louder than the rest (not unreasonable - that is the difference between a conversation and street noise according to [http://www.acousticalsurfaces.com/acoustic_IOI/101_4.htm| this page]). <br />
If each extra bit adds 6dB of dynamic range, then the quiter sections will effectively be quantized using roughly 3 fewer bits than the louder section (e.g. 13bits rather than 16bits).<br />
If the majority of the content relatively quite (ie. being quantized using 13bits or less depending on how quiet relative to the peaks) then is it really fair to claim "16bit quality" for the entire piece of conetnet?<br />
Is this a real problem?? Is this ever an audible? <br />
[[User:Klodj|Klodj]] 21:59, 11 March 2013 (PDT)<br />
<br />
: the bit depth doesn't affect the correctness or 'fineness' of the reconstruction, it only changes the noise floor. It is the same and sounds the same as what happens when recording quieter-than-full-range on analogue tape. Compare a 16-bit digital signal recorded at -20dBFS to the same signal recorded on tape at -20dBV. Both will be smooth and analogue, but the tape will be noisier ;-) --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
:: Thank you for your reply! Ok, I understand that, when comparing digital to "analog" (tape), this is a non-issue. The tape noise floor is higher. But could you clarify a related point that is entirely in the digital domain? Lets say we have a 16bit recording of the 1812 Overture where the canons don't clip. The average level is going to depend on how dynamic range is compressed to handle the canons, but lets say it -36dBFS. If I adjust volume to suit the average level, then won't I effectively be hearing a noise floor equivalent to 10 bit quantization (16 bits - 36dB/6db_per_bit) for the majority of the recording (dither aside). --[[User:Klodj|Klodj]] 19:13, 13 March 2013 (PDT)<br />
<br />
::: Yes. --[[User:Xiphmont|Xiphmont]] 00:54, 14 March 2013 (PDT)<br />
<br />
I've really enjoyed your videos, many thanks for your work producing them. In keeping with your message in the video about breaking things I was curious to see what would happen as you pushed the signal up to and beyond the Nyquist frequency. Would the filters mean that it would simply fade out smoothly (what order filter is employed?)? I suppose I could check this out myself, but would be interested to hear your answer. Also is the Gibbs phenomenon audible to any degree? --[[User:Stuarticus|Stuarticus]] 14:00, 11 June 2013 (PDT)<br />
<br />
: If the filter is smooth, it will fade smoothly. If the filter is sharp, it will drop off suddenly. Some DACs put the transition band of the anti-imaging filters straddling the Nyquist frequency or slightly past, so you might even see the signal fold back about Nyquist as it drops off (this used to be more common about 10 years ago). So long as no significant aliasing reaches back under 20kHz, this is just one of many arbitrary design decisions that don't really affect the audio quality. The order of the digital filter used in the upsampling stage can be nearly anything, but they're not likely to be as huge as many software resampling filters, where a linear-phase FIR of 512 or 1024 taps is common. The analog filter stages, if they're there at all, are unlikely to be more than a handful of taps. Detailed spec sheets should say outright, and if they don't they should at least usually mention the approximate slope.</div>Xiphmonthttps://wiki.xiph.org/index.php?title=Talk:Videos/Digital_Show_and_Tell&diff=14189Talk:Videos/Digital Show and Tell2013-06-14T18:16:27Z<p>Xiphmont: jkorten-- please go watch the _whole_ video, then try again. An argument isn't simply saying 'no it isn't', and this is a place for questions and discussion, not rants.</p>
<hr />
<div>Greetings, Feel free to comment here— just log in to edit— or join us on [http://webchat.freenode.net/?channels=xiph IRC chat]. <br />
<br />
The wiki version of the video isn't yet as complete as the last video, due to schedules and timelines. In particular I think it could use some more going-deeper coverage. I'm surprised that I couldn't better HTML5 audio api examples of the "type your own JS, get audio and a scope" kind, if anyone knows of a better one than the one we have now that would be great.<br />
<br />
--[[User:Gmaxwell|Gmaxwell]] 02:54, 26 February 2013 (PST)<br />
<br />
Just dropping a line to say thank you! I'm continually impressed by the guides and overall outreach coming out of the xiph team. The latest video was a great introduction that managed to walk that fine line between theory and application without falling over or flailing about madly (in my opinion, anyway). Not to mention, I'm going through the gtk-bounce and waveform code now and really like it! It's not so trivial a piece of software as to be meaningless when learning to code useful applications, but it's not so gigantic as to be unapproachable either. Hell, I think it would serve as a great example for the GNOME folks to use in their documentation. Most guides on GTK just have you draw shapes on the screen and leave it at that. All in all, I'm really impressed and hope to have a similar setup replicated in a few weeks at my university, just for the sake of it.<br />
<br />
--[[User:Aggroskater|Aggroskater]] 23:16, 26 February 2013 (PST)<br />
<br />
: Some parts are better written than others... I used enough cut & paste to warn against taking it too seriously :-) --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
@Monty: Thanks for these information. And as a non-native English speaker I want to thank you for your clear pronunciation.<br />
What did you mean with "no one ever ruined a great recording by not dithering the final master."? Do you mean, that nobody ever would forget it, or that it was not ruinous?<br />
That "CSS is awesome"-cup made me really nervous. I hope it means something like "Cascading Style Sheets", and not, what would fit better in this context, "Content Scramble System"[shudder]!<br />
--[[User:Akf|Akf]] 15:20, 27 February 2013 (PST)<br />
<br />
: I meant that "not adding dither is not ruinous". I recall in at least one listening test on the subject, a minority of participants had a statistically significant preference for undithered versions, at least on those samples where it was in fact audible and the testers were encouraged to increase gain and listen to fade-outs. *However* I can't find the results of that test now that I've gone back to look for it, so my memory may be faulty. I've asked the HA folks to help me find it again if it really existed :-) <br />
:CSS refers to [[WikiPedia:Cascading Style Sheets|Cascading Style Sheets]]. Thus the typsetting that overflows the box. --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
: I once built an 8-bit ADC from transistors, for experimentation. One strange result was how few bits are needed for speech. 8kHz with just one bit resolution is still quite intelligible (though rather noisy). --[[User:RichardNeill|RichardNeill]] 08:08, 4 March 2013 (PST)<br />
<br />
Thanks for these resources! One question: In the vid, you mention the Gibbs phenomenon. Is that in any way related to the Fourier uncertainty principle? These days, in various audio-related forums, people throw this Oppenheim and Magnasco (2013) paper entitled "Human hearing beats the Fourier uncertainty principle" around in response to your 24/192 article. Does the paper qualify any of the results presented in the video and/or your 24/192 article? (Just fixed the reference.) [[User:Lenfaki|Lenfaki]] 13:14, 28 February 2013 (PST)<br />
<br />
: it is related to the fourier uncertainty principle in that all of these effects are in some way related by the same math. As for the "Human hearing beats the Fourier uncertainty principle" paper floating around, a) the headline is effectively wrong, b) the effect described as 'newly discovered' has been understood for roughly 100 years, this merely adds some new hard measurements to the data set, c) the Gabor limit does not even apply to the detection task they're describing. So either the authors or their editor are partly confused. [http://www.hydrogenaudio.org/forums/index.php?showtopic=99371| There's been a decent discussion of it at Hydrogen Audio], with none other than James Johnston and Ethan Winer weighing in. --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
<br />
You talk about discrete values (whether the analog sample points, or the infinitesimal image pixels). BUT, these are in some way, averages. In a digital camera, the pixel value is the integral across about 90% of the pixel-pitch. In analog audio, is it an instantaneous sample, or an average over the preceding sample-interval, or is it sometimes even more "blurred" than that? Also, when performing DAC, how do we get rid of the stairstep so perfectly without distortion? --[[User:RichardNeill|RichardNeill]] 07:51, 4 March 2013 (PST)<br />
<br />
: The pixel values in a camera are area averages exactly as you say, a necessary compromise in order to have enough light to work with. The sensor sits behind an optical lowpass filter that is intentionally blurring the image to prevent much of the aliasing distortion (Moiré) that would otherwise occur. Despite that, cameras still alias a bit, and if you _remove_ that anti-aliasing filter, you get much more (I have such a camera, danged filter was bonded to the hot filter, so both had to go to photograph hydrogen alpha lines).<br />
<br />
: Audio does in fact use as close to an instantaneous sample as possible. The 'stairsteps' of a zero-order hold are quite regular in the frequency domain; they're folded mirror images of the original spectrum extending to infinity. All the anti-imaging filter has to do is cut off everything above the original channel bandwidth, and it doesn't even have to do a great job to beat a human ear :-) --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
What's the correct way to plot a reconstructed waveform? If I have an array of samples and play them back through a DAC, the oscilloscope shows a smooth curve. But plotting them with eg matplotlib shows a stairstep. Thanks --[[User:RichardNeill|RichardNeill]] 07:58, 4 March 2013 (PST)<br />
<br />
: well, a fully reconstructed waveform is equal to the original input; it's a smooth continuous waveform. OTOH, if you want to plot an actual zero-order hold, a zero order hold really is a staircase waveform.<br />
<br />
: If you want to plot the digital waveform pre-reconstruction, a mathemetician would always use lollipops, an engineer will use whatever's the most convenient. --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
<br />
I have a strange issue with the gtk-bounce program - on (k)ubuntu 12.10, spectrum and waveform work just fine, but if I scroll into the gtk-bounce panel, the cursor disappears. Anyone seen that behaviour? - Julf<br />
<br />
: Edit out the calls to "hide_mouse()" in gtk-bounce-widget.c. It's hiding the mouse on purpose because it's supposedly a touch application :-) --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
One issue I'm not sure you have covered, relates content with short, loud sections (e.g. more like a movie or maybe classical music, less like pop music). <br />
I understand that that a 10dB change in sound level is perceived as twice as loud. <br />
Lets say we have some content where one section is 4 times (20dB) louder than the rest (not unreasonable - that is the difference between a conversation and street noise according to [http://www.acousticalsurfaces.com/acoustic_IOI/101_4.htm| this page]). <br />
If each extra bit adds 6dB of dynamic range, then the quiter sections will effectively be quantized using roughly 3 fewer bits than the louder section (e.g. 13bits rather than 16bits).<br />
If the majority of the content relatively quite (ie. being quantized using 13bits or less depending on how quiet relative to the peaks) then is it really fair to claim "16bit quality" for the entire piece of conetnet?<br />
Is this a real problem?? Is this ever an audible? <br />
[[User:Klodj|Klodj]] 21:59, 11 March 2013 (PDT)<br />
<br />
: the bit depth doesn't affect the correctness or 'fineness' of the reconstruction, it only changes the noise floor. It is the same and sounds the same as what happens when recording quieter-than-full-range on analogue tape. Compare a 16-bit digital signal recorded at -20dBFS to the same signal recorded on tape at -20dBV. Both will be smooth and analogue, but the tape will be noisier ;-) --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
:: Thank you for your reply! Ok, I understand that, when comparing digital to "analog" (tape), this is a non-issue. The tape noise floor is higher. But could you clarify a related point that is entirely in the digital domain? Lets say we have a 16bit recording of the 1812 Overture where the canons don't clip. The average level is going to depend on how dynamic range is compressed to handle the canons, but lets say it -36dBFS. If I adjust volume to suit the average level, then won't I effectively be hearing a noise floor equivalent to 10 bit quantization (16 bits - 36dB/6db_per_bit) for the majority of the recording (dither aside). --[[User:Klodj|Klodj]] 19:13, 13 March 2013 (PDT)<br />
<br />
::: Yes. --[[User:Xiphmont|Xiphmont]] 00:54, 14 March 2013 (PDT)<br />
<br />
I've really enjoyed your videos, many thanks for your work producing them. In keeping with your message in the video about breaking things I was curious to see what would happen as you pushed the signal up to and beyond the Nyquist frequency. Would the filters mean that it would simply fade out smoothly (what order filter is employed?)? I suppose I could check this out myself, but would be interested to hear your answer. Also is the Gibbs phenomenon audible to any degree? --[[User:Stuarticus|Stuarticus]] 14:00, 11 June 2013 (PDT)</div>Xiphmonthttps://wiki.xiph.org/index.php?title=Talk:Videos/Digital_Show_and_Tell&diff=14067Talk:Videos/Digital Show and Tell2013-03-14T07:54:05Z<p>Xiphmont: </p>
<hr />
<div>Greetings, Feel free to comment here— just log in to edit— or join us on [http://webchat.freenode.net/?channels=xiph IRC chat]. <br />
<br />
The wiki version of the video isn't yet as complete as the last video, due to schedules and timelines. In particular I think it could use some more going-deeper coverage. I'm surprised that I couldn't better HTML5 audio api examples of the "type your own JS, get audio and a scope" kind, if anyone knows of a better one than the one we have now that would be great.<br />
<br />
--[[User:Gmaxwell|Gmaxwell]] 02:54, 26 February 2013 (PST)<br />
<br />
Just dropping a line to say thank you! I'm continually impressed by the guides and overall outreach coming out of the xiph team. The latest video was a great introduction that managed to walk that fine line between theory and application without falling over or flailing about madly (in my opinion, anyway). Not to mention, I'm going through the gtk-bounce and waveform code now and really like it! It's not so trivial a piece of software as to be meaningless when learning to code useful applications, but it's not so gigantic as to be unapproachable either. Hell, I think it would serve as a great example for the GNOME folks to use in their documentation. Most guides on GTK just have you draw shapes on the screen and leave it at that. All in all, I'm really impressed and hope to have a similar setup replicated in a few weeks at my university, just for the sake of it.<br />
<br />
--[[User:Aggroskater|Aggroskater]] 23:16, 26 February 2013 (PST)<br />
<br />
: Some parts are better written than others... I used enough cut & paste to warn against taking it too seriously :-) --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
@Monty: Thanks for these information. And as a non-native English speaker I want to thank you for your clear pronunciation.<br />
What did you mean with "no one ever ruined a great recording by not dithering the final master."? Do you mean, that nobody ever would forget it, or that it was not ruinous?<br />
That "CSS is awesome"-cup made me really nervous. I hope it means something like "Cascading Style Sheets", and not, what would fit better in this context, "Content Scramble System"[shudder]!<br />
--[[User:Akf|Akf]] 15:20, 27 February 2013 (PST)<br />
<br />
: I meant that "not adding dither is not ruinous". I recall in at least one listening test on the subject, a minority of participants had a statistically significant preference for undithered versions, at least on those samples where it was in fact audible and the testers were encouraged to increase gain and listen to fade-outs. *However* I can't find the results of that test now that I've gone back to look for it, so my memory may be faulty. I've asked the HA folks to help me find it again if it really existed :-) <br />
:CSS refers to [[WikiPedia:Cascading Style Sheets|Cascading Style Sheets]]. Thus the typsetting that overflows the box. --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
: I once built an 8-bit ADC from transistors, for experimentation. One strange result was how few bits are needed for speech. 8kHz with just one bit resolution is still quite intelligible (though rather noisy). --[[User:RichardNeill|RichardNeill]] 08:08, 4 March 2013 (PST)<br />
<br />
Thanks for these resources! One question: In the vid, you mention the Gibbs phenomenon. Is that in any way related to the Fourier uncertainty principle? These days, in various audio-related forums, people throw this Oppenheim and Magnasco (2013) paper entitled "Human hearing beats the Fourier uncertainty principle" around in response to your 24/192 article. Does the paper qualify any of the results presented in the video and/or your 24/192 article? (Just fixed the reference.) [[User:Lenfaki|Lenfaki]] 13:14, 28 February 2013 (PST)<br />
<br />
: it is related to the fourier uncertainty principle in that all of these effects are in some way related by the same math. As for the "Human hearing beats the Fourier uncertainty principle" paper floating around, a) the headline is effectively wrong, b) the effect described as 'newly discovered' has been understood for roughly 100 years, this merely adds some new hard measurements to the data set, c) the Gabor limit does not even apply to the detection task they're describing. So either the authors or their editor are partly confused. [http://www.hydrogenaudio.org/forums/index.php?showtopic=99371| There's been a decent discussion of it at Hydrogen Audio], with none other than James Johnston and Ethan Winer weighing in. --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
<br />
You talk about discrete values (whether the analog sample points, or the infinitesimal image pixels). BUT, these are in some way, averages. In a digital camera, the pixel value is the integral across about 90% of the pixel-pitch. In analog audio, is it an instantaneous sample, or an average over the preceding sample-interval, or is it sometimes even more "blurred" than that? Also, when performing DAC, how do we get rid of the stairstep so perfectly without distortion? --[[User:RichardNeill|RichardNeill]] 07:51, 4 March 2013 (PST)<br />
<br />
: The pixel values in a camera are area averages exactly as you say, a necessary compromise in order to have enough light to work with. The sensor sits behind an optical lowpass filter that is intentionally blurring the image to prevent much of the aliasing distortion (Moiré) that would otherwise occur. Despite that, cameras still alias a bit, and if you _remove_ that anti-aliasing filter, you get much more (I have such a camera, danged filter was bonded to the hot filter, so both had to go to photograph hydrogen alpha lines).<br />
<br />
: Audio does in fact use as close to an instantaneous sample as possible. The 'stairsteps' of a zero-order hold are quite regular in the frequency domain; they're folded mirror images of the original spectrum extending to infinity. All the anti-imaging filter has to do is cut off everything above the original channel bandwidth, and it doesn't even have to do a great job to beat a human ear :-) --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
What's the correct way to plot a reconstructed waveform? If I have an array of samples and play them back through a DAC, the oscilloscope shows a smooth curve. But plotting them with eg matplotlib shows a stairstep. Thanks --[[User:RichardNeill|RichardNeill]] 07:58, 4 March 2013 (PST)<br />
<br />
: well, a fully reconstructed waveform is equal to the original input; it's a smooth continuous waveform. OTOH, if you want to plot an actual zero-order hold, a zero order hold really is a staircase waveform.<br />
<br />
: If you want to plot the digital waveform pre-reconstruction, a mathemetician would always use lollipops, an engineer will use whatever's the most convenient. --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
<br />
I have a strange issue with the gtk-bounce program - on (k)ubuntu 12.10, spectrum and waveform work just fine, but if I scroll into the gtk-bounce panel, the cursor disappears. Anyone seen that behaviour? - Julf<br />
<br />
: Edit out the calls to "hide_mouse()" in gtk-bounce-widget.c. It's hiding the mouse on purpose because it's supposedly a touch application :-) --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
One issue I'm not sure you have covered, relates content with short, loud sections (e.g. more like a movie or maybe classical music, less like pop music). <br />
I understand that that a 10dB change in sound level is perceived as twice as loud. <br />
Lets say we have some content where one section is 4 times (20dB) louder than the rest (not unreasonable - that is the difference between a conversation and street noise according to [http://www.acousticalsurfaces.com/acoustic_IOI/101_4.htm| this page]). <br />
If each extra bit adds 6dB of dynamic range, then the quiter sections will effectively be quantized using roughly 3 fewer bits than the louder section (e.g. 13bits rather than 16bits).<br />
If the majority of the content relatively quite (ie. being quantized using 13bits or less depending on how quiet relative to the peaks) then is it really fair to claim "16bit quality" for the entire piece of conetnet?<br />
Is this a real problem?? Is this ever an audible? <br />
[[User:Klodj|Klodj]] 21:59, 11 March 2013 (PDT)<br />
<br />
: the bit depth doesn't affect the correctness or 'fineness' of the reconstruction, it only changes the noise floor. It is the same and sounds the same as what happens when recording quieter-than-full-range on analogue tape. Compare a 16-bit digital signal recorded at -20dBFS to the same signal recorded on tape at -20dBV. Both will be smooth and analogue, but the tape will be noisier ;-) --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
:: Thank you for your reply! Ok, I understand that, when comparing digital to "analog" (tape), this is a non-issue. The tape noise floor is higher. But could you clarify a related point that is entirely in the digital domain? Lets say we have a 16bit recording of the 1812 Overture where the canons don't clip. The average level is going to depend on how dynamic range is compressed to handle the canons, but lets say it -36dBFS. If I adjust volume to suit the average level, then won't I effectively be hearing a noise floor equivalent to 10 bit quantization (16 bits - 36dB/6db_per_bit) for the majority of the recording (dither aside). --[[User:Klodj|Klodj]] 19:13, 13 March 2013 (PDT)<br />
<br />
::: Yes. --[[User:Xiphmont|Xiphmont]] 00:54, 14 March 2013 (PDT)</div>Xiphmonthttps://wiki.xiph.org/index.php?title=Talk:Videos/Digital_Show_and_Tell&diff=14064Talk:Videos/Digital Show and Tell2013-03-12T09:56:13Z<p>Xiphmont: </p>
<hr />
<div>Greetings, Feel free to comment here— just log in to edit— or join us on [http://webchat.freenode.net/?channels=xiph IRC chat]. <br />
<br />
The wiki version of the video isn't yet as complete as the last video, due to schedules and timelines. In particular I think it could use some more going-deeper coverage. I'm surprised that I couldn't better HTML5 audio api examples of the "type your own JS, get audio and a scope" kind, if anyone knows of a better one than the one we have now that would be great.<br />
<br />
--[[User:Gmaxwell|Gmaxwell]] 02:54, 26 February 2013 (PST)<br />
<br />
Just dropping a line to say thank you! I'm continually impressed by the guides and overall outreach coming out of the xiph team. The latest video was a great introduction that managed to walk that fine line between theory and application without falling over or flailing about madly (in my opinion, anyway). Not to mention, I'm going through the gtk-bounce and waveform code now and really like it! It's not so trivial a piece of software as to be meaningless when learning to code useful applications, but it's not so gigantic as to be unapproachable either. Hell, I think it would serve as a great example for the GNOME folks to use in their documentation. Most guides on GTK just have you draw shapes on the screen and leave it at that. All in all, I'm really impressed and hope to have a similar setup replicated in a few weeks at my university, just for the sake of it.<br />
<br />
--[[User:Aggroskater|Aggroskater]] 23:16, 26 February 2013 (PST)<br />
<br />
: Some parts are better written than others... I used enough cut & paste to warn against taking it too seriously :-) --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
@Monty: Thanks for these information. And as a non-native English speaker I want to thank you for your clear pronunciation.<br />
What did you mean with "no one ever ruined a great recording by not dithering the final master."? Do you mean, that nobody ever would forget it, or that it was not ruinous?<br />
That "CSS is awesome"-cup made me really nervous. I hope it means something like "Cascading Style Sheets", and not, what would fit better in this context, "Content Scramble System"[shudder]!<br />
--[[User:Akf|Akf]] 15:20, 27 February 2013 (PST)<br />
<br />
: I meant that "not adding dither is not ruinous". I recall in at least one listening test on the subject, a minority of participants had a statistically significant preference for undithered versions, at least on those samples where it was in fact audible and the testers were encouraged to increase gain and listen to fade-outs. *However* I can't find the results of that test now that I've gone back to look for it, so my memory may be faulty. I've asked the HA folks to help me find it again if it really existed :-) <br />
:CSS refers to [[WikiPedia:Cascading Style Sheets|Cascading Style Sheets]]. Thus the typsetting that overflows the box. --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
: I once built an 8-bit ADC from transistors, for experimentation. One strange result was how few bits are needed for speech. 8kHz with just one bit resolution is still quite intelligible (though rather noisy). --[[User:RichardNeill|RichardNeill]] 08:08, 4 March 2013 (PST)<br />
<br />
Thanks for these resources! One question: In the vid, you mention the Gibbs phenomenon. Is that in any way related to the Fourier uncertainty principle? These days, in various audio-related forums, people throw this Oppenheim and Magnasco (2013) paper entitled "Human hearing beats the Fourier uncertainty principle" around in response to your 24/192 article. Does the paper qualify any of the results presented in the video and/or your 24/192 article? (Just fixed the reference.) [[User:Lenfaki|Lenfaki]] 13:14, 28 February 2013 (PST)<br />
<br />
: it is related to the fourier uncertainty principle in that all of these effects are in some way related by the same math. As for the "Human hearing beats the Fourier uncertainty principle" paper floating around, a) the headline is effectively wrong, b) the effect described as 'newly discovered' has been understood for roughly 100 years, this merely adds some new hard measurements to the data set, c) the Gabor limit does not even apply to the detection task they're describing. So either the authors or their editor are partly confused. [http://www.hydrogenaudio.org/forums/index.php?showtopic=99371| There's been a decent discussion of it at Hydrogen Audio], with none other than James Johnston and Ethan Winer weighing in. --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
<br />
You talk about discrete values (whether the analog sample points, or the infinitesimal image pixels). BUT, these are in some way, averages. In a digital camera, the pixel value is the integral across about 90% of the pixel-pitch. In analog audio, is it an instantaneous sample, or an average over the preceding sample-interval, or is it sometimes even more "blurred" than that? Also, when performing DAC, how do we get rid of the stairstep so perfectly without distortion? --[[User:RichardNeill|RichardNeill]] 07:51, 4 March 2013 (PST)<br />
<br />
: The pixel values in a camera are area averages exactly as you say, a necessary compromise in order to have enough light to work with. The sensor sits behind an optical lowpass filter that is intentionally blurring the image to prevent much of the aliasing distortion (Moiré) that would otherwise occur. Despite that, cameras still alias a bit, and if you _remove_ that anti-aliasing filter, you get much more (I have such a camera, danged filter was bonded to the hot filter, so both had to go to photograph hydrogen alpha lines).<br />
<br />
: Audio does in fact use as close to an instantaneous sample as possible. The 'stairsteps' of a zero-order hold are quite regular in the frequency domain; they're folded mirror images of the original spectrum extending to infinity. All the anti-imaging filter has to do is cut off everything above the original channel bandwidth, and it doesn't even have to do a great job to beat a human ear :-) --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
What's the correct way to plot a reconstructed waveform? If I have an array of samples and play them back through a DAC, the oscilloscope shows a smooth curve. But plotting them with eg matplotlib shows a stairstep. Thanks --[[User:RichardNeill|RichardNeill]] 07:58, 4 March 2013 (PST)<br />
<br />
: well, a fully reconstructed waveform is equal to the original input; it's a smooth continuous waveform. OTOH, if you want to plot an actual zero-order hold, a zero order hold really is a staircase waveform.<br />
<br />
: If you want to plot the digital waveform pre-reconstruction, a mathemetician would always use lollipops, an engineer will use whatever's the most convenient. --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
<br />
I have a strange issue with the gtk-bounce program - on (k)ubuntu 12.10, spectrum and waveform work just fine, but if I scroll into the gtk-bounce panel, the cursor disappears. Anyone seen that behaviour? - Julf<br />
<br />
: Edit out the calls to "hide_mouse()" in gtk-bounce-widget.c. It's hiding the mouse on purpose because it's supposedly a touch application :-) --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)<br />
<br />
One issue I'm not sure you have covered, relates content with short, loud sections (e.g. more like a movie or maybe classical music, less like pop music). <br />
I understand that that a 10dB change in sound level is perceived as twice as loud. <br />
Lets say we have some content where one section is 4 times (20dB) louder than the rest (not unreasonable - that is the difference between a conversation and street noise according to [http://www.acousticalsurfaces.com/acoustic_IOI/101_4.htm| this page]). <br />
If each extra bit adds 6dB of dynamic range, then the quiter sections will effectively be quantized using roughly 3 fewer bits than the louder section (e.g. 13bits rather than 16bits).<br />
If the majority of the content relatively quite (ie. being quantized using 13bits or less depending on how quiet relative to the peaks) then is it really fair to claim "16bit quality" for the entire piece of conetnet?<br />
Is this a real problem?? Is this ever an audible? <br />
[[User:Klodj|Klodj]] 21:59, 11 March 2013 (PDT)<br />
<br />
: the bit depth doesn't affect the correctness or 'fineness' of the reconstruction, it only changes the noise floor. It is the same and sounds the same as what happens when recording quieter-than-full-range on analogue tape. Compare a 16-bit digital signal recorded at -20dBFS to the same signal recorded on tape at -20dBV. Both will be smooth and analogue, but the tape will be noisier ;-) --[[User:Xiphmont|Xiphmont]] 02:56, 12 March 2013 (PDT)</div>Xiphmonthttps://wiki.xiph.org/index.php?title=Talk:Videos/Digital_Show_and_Tell&diff=14052Talk:Videos/Digital Show and Tell2013-02-28T18:52:01Z<p>Xiphmont: </p>
<hr />
<div>Greetings, Feel free to comment here— just log in to edit— or join us on [http://webchat.freenode.net/?channels=xiph IRC chat]. <br />
<br />
The wiki version of the video isn't yet as complete as the last video, due to schedules and timelines. In particular I think it could use some more going-deeper coverage. I'm surprised that I couldn't better HTML5 audio api examples of the "type your own JS, get audio and a scope" kind, if anyone knows of a better one than the one we have now that would be great.<br />
<br />
--[[User:Gmaxwell|Gmaxwell]] 02:54, 26 February 2013 (PST)<br />
<br />
Just dropping a line to say thank you! I'm continually impressed by the guides and overall outreach coming out of the xiph team. The latest video was a great introduction that managed to walk that fine line between theory and application without falling over or flailing about madly (in my opinion, anyway). Not to mention, I'm going through the gtk-bounce and waveform code now and really like it! It's not so trivial a piece of software as to be meaningless when learning to code useful applications, but it's not so gigantic as to be unapproachable either. Hell, I think it would serve as a great example for the GNOME folks to use in their documentation. Most guides on GTK just have you draw shapes on the screen and leave it at that. All in all, I'm really impressed and hope to have a similar setup replicated in a few weeks at my university, just for the sake of it.<br />
<br />
--[[User:Aggroskater|Aggroskater]] 23:16, 26 February 2013 (PST)<br />
<br />
: Some parts are better written than others... I used enough cut & paste to warn against taking it too seriously :-) --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
@Monty: Thanks for these information. And as a non-native English speaker I want to thank you for your clear pronunciation.<br />
What did you mean with "no one ever ruined a great recording by not dithering the final master."? Do you mean, that nobody ever would forget it, or that it was not ruinous?<br />
That "CSS is awesome"-cup made me really nervous. I hope it means something like "Cascading Style Sheets", and not, what would fit better in this context, "Content Scramble System"[shudder]!<br />
--[[User:Akf|Akf]] 15:20, 27 February 2013 (PST)<br />
<br />
: I meant that "not adding dither is not ruinous". I recall in at least one listening test on the subject, a minority of participants had a statistically significant preference for undithered versions, at least on those samples where it was in fact audible and the testers were encouraged to increase gain and listen to fade-outs. *However* I can't find the results of that test now that I've gone back to look for it, so my memory may be faulty. I've asked the HA folks to help me find it again if it really existed :-) <br />
:CSS refers to Cascading Style Sheets. Thus the typsetting that overflows the box. --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
Thanks for these resources! One question: In the vid, you mention the Gibbs phenomenon. Is that in any way related to the Fourier uncertainty principle? These days, in various audio-related forums, people throw this Zyga (2013) paper entitled "Human hearing beats the Fourier uncertainty principle" around in response to your 24/192 article. Does Zyga qualify any of the results presented in the video and/or your 24/192 article?<br />
<br />
: it is related to the fourier uncertainty principle in that all of these effects are in some way related by the same math. As for the "Human hearing beats the Fourier uncertainty principle" paper floating around, a) the headline is effectively wrong, b) the effect described as 'newly discovered' has been understood for roughly 100 years, this merely adds some new hard measurements to the data set, c) the Gabor limit does not even apply to the detection task they're describing. So either the authors or their editor are partly confused. [http://www.hydrogenaudio.org/forums/index.php?showtopic=99371| There's been a decent discussion of it at Hydrogen Audio], with none other than James Johnston and Ethan Winer weighing in. --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)</div>Xiphmonthttps://wiki.xiph.org/index.php?title=Talk:Videos/Digital_Show_and_Tell&diff=14051Talk:Videos/Digital Show and Tell2013-02-28T18:50:56Z<p>Xiphmont: respond to peeps!</p>
<hr />
<div>Greetings, Feel free to comment here— just log in to edit— or join us on [http://webchat.freenode.net/?channels=xiph IRC chat]. <br />
<br />
The wiki version of the video isn't yet as complete as the last video, due to schedules and timelines. In particular I think it could use some more going-deeper coverage. I'm surprised that I couldn't better HTML5 audio api examples of the "type your own JS, get audio and a scope" kind, if anyone knows of a better one than the one we have now that would be great.<br />
<br />
--[[User:Gmaxwell|Gmaxwell]] 02:54, 26 February 2013 (PST)<br />
<br />
Just dropping a line to say thank you! I'm continually impressed by the guides and overall outreach coming out of the xiph team. The latest video was a great introduction that managed to walk that fine line between theory and application without falling over or flailing about madly (in my opinion, anyway). Not to mention, I'm going through the gtk-bounce and waveform code now and really like it! It's not so trivial a piece of software as to be meaningless when learning to code useful applications, but it's not so gigantic as to be unapproachable either. Hell, I think it would serve as a great example for the GNOME folks to use in their documentation. Most guides on GTK just have you draw shapes on the screen and leave it at that. All in all, I'm really impressed and hope to have a similar setup replicated in a few weeks at my university, just for the sake of it.<br />
<br />
--[[User:Aggroskater|Aggroskater]] 23:16, 26 February 2013 (PST)<br />
<br />
: Some parts are better written than others... I used enough cut & paste to warn against taking it too seriously :-) --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
@Monty: Thanks for these information. And as a non-native English speaker I want to thank you for your clear pronunciation.<br />
What did you mean with "no one ever ruined a great recording by not dithering the final master."? Do you mean, that nobody ever would forget it, or that it was not ruinous?<br />
That "CSS is awesome"-cup made me really nervous. I hope it means something like "Cascading Style Sheets", and not, what would fit better in this context, "Content Scramble System"[shudder]!<br />
--[[User:Akf|Akf]] 15:20, 27 February 2013 (PST)<br />
<br />
: I meant that "not adding dither is not ruinous". I recall in at least one listening test on the subject, a minority of participants had a statistically significant preference for undithered versions, at least on those samples where it was in fact audible and the testers were encouraged to increase gain and listen to fade-outs. *However* I can't find the results of that test now that I've gone back to look for it, so my memory may be faulty. I've asked the HA folks to help me find it again if it really existed :-) <br />
:CSS refers to Cascading Style Sheets. Thus the typsetting that overflows the box. --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)<br />
<br />
Thanks for these resources! One question: In the vid, you mention the Gibbs phenomenon. Is that in any way related to the Fourier uncertainty principle? These days, in various audio-related forums, people throw this Zyga (2013) paper entitled "Human hearing beats the Fourier uncertainty principle" around in response to your 24/192 article. Does Zyga qualify any of the results presented in the video and/or your 24/192 article?<br />
<br />
: it is related to the fourier uncertainty principle in that all of these effects are in some way related byt the same math. As for the "Human hearing beats the Fourier uncertainty principle" paper floating around, a) the headline is effectively wrong, b) the effect described as 'newly discovered' has been understood for roughly 100 years, this merely adds some new hard measurements to the data set, c) the Gabor limit does not even apply to the detection task they're describing. So either the authors or their editor are partly confused. [http://www.hydrogenaudio.org/forums/index.php?showtopic=99371| There's been a decent discussion of it at Hydrogen Audio], with none other than James Johnston and Ethan Winer weighing in. --[[User:Xiphmont|Xiphmont]] 10:50, 28 February 2013 (PST)</div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14048Videos/Digital Show and Tell2013-02-27T18:46:08Z<p>Xiphmont: speling</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 007.png|360px|right]]<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
First demo: We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before and we can see the analog sine wave on the input-side oscilloscope. The eMagic digitizes our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD. The spectrum of the digitized signal on the Thinkpad matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier. For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
When we look at the output signal that's been converted<br />
from digital back to analog, we see that it's exactly like the original sine wave. No stairsteps.<br />
<br />
1 kHz is still a fairly low frequency, so perhaps the stairsteps are just<br />
hard to see or they're being smoothed away. Next, set the signal generator to 15kHz, which is much closer to [[WikiPedia:Nyquist_frequency|Nyquist]].<br />
Now the sine wave is represented by less than three samples per cycle, and the digital waveform appears rather poor! Yet the analog output is still a perfect sine wave, exactly like the original.<br />
As we keep increasing frequency, all the way to 20kHz, the output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? It's a trick question; they were never there. Drawing a digital waveform as a stairstep was wrong to begin with.<br />
<br />
A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.<br />
A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.<br />
The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
The interesting and non-obvious bit is that [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]; it's a unique solution. If you sample a bandlimited signal and then convert it back, the original input is also the only possible output.<br />
A signal that differs even minutely from the original includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
As a result, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better (yes, even I) draw stairsteps even though they're<br />
technically wrong. It's a sort of one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is.<br />
<br />
Digital stairstep drawings are exactly the same thing. It's just a convenient drawing. The stairsteps aren't really there.<br />
<div style="clear:both"></div><br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. It doesn't matter if it's 24 bits or 16 bits or 8 bits.<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 is the same sine wave input, but we quantize it with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal, our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher. And that's the difference, the only difference, the number of bits makes.<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like?<br />
Those of you who have used analog recording equipment might think to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]], for those of you who are old enough to remember them, could reach as<br />
deep as 9 bits in perfect conditions. 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right; your old mix tapes were only about 6 bits<br />
deep if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. <br />
That's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
<div style="clear:both"></div><br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
We've been quantizing with [[Wikipedia:dither|dither]]. What is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simplest way to quantize a signal is to choose the digital<br />
amplitude value [[WikiPedia:Rounding|closest to the original analog amplitude]].<br />
Unfortunately, the exact noise that results from this simple<br />
quantization scheme depends somewhat on the input signal.<br />
It may be inconsistent, cause distortion, or be<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div>&nbsp;</center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
The signal generator has too much noise for this test so we produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
We see the sine wave on waveform display and output scope, and <br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible. Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. When we reenable dither, we clearly see our signal at 1/4 bit with a nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so it makes sense to choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Human hearing is [[WikiPedia:Equal-loudness_contour|most sensitive in the midrange from 2kHz to 4kHz]]; that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise, even though it often sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. However,<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
For the next test, we also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect.<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage; it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all this text spent on dither, the differences exist 100 decibels or more below [[WikiPedia:Full_scale|full scale]]. If the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
perhaps dither ''might'' be<br />
more important. At 16 bits it's mostly a wash. It's reasonable to treat<br />
dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. That said no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]? <br />
<br />
The input scope confirms a 1kHz square wave. The output scope shows... exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
We can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ squarewave(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
We remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]].<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
\ squarewave(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either; you'd have to sum an infinite number of harmonics to get the answer! However, we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]]. Only the first ten terms make it through, and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<div>&nbsp;</div><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it. For example, what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is:<br />
Nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
That's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We see that in this case that didn't happen, so<br />
it wasn't really the filter that added the ripples the first time<br />
through. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave it's still limited to the channel bandwidth. Remember that<br />
the stairstep representation is misleading. What we really have here are instantaneous sample points<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]]. The original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
That leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way, that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled or they just disappear.<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Like in [[Videos/A_Digital_Media_Primer_For_Geeks|_A Digital Media Primer for Geeks_]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around.<br />
<br />
Thus I encourage you to dig deeper and experiment. I chose my<br />
demos carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like, but let's face<br />
it: Sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is at the [[Videos/Digital_Show_and_Tell#Use_The_Source_Luke|bottom of this page]].<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. If you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<hr/><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and [http://sourceforge.net/projects/gromit-mpx/ Gromit]).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and down with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14036Videos/Digital Show and Tell2013-02-26T11:02:19Z<p>Xiphmont: /* Epilogue */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
First demo: We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before and we can see the analog sine wave on the input-side oscilloscope. The eMagic digitizes our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD. The spectrum of the digitized signal on the Thinkpad matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier. For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
When we look at the output signal that's been converted<br />
from digital back to analog, we see that it's exactly like the original sine wave. No stairsteps.<br />
<br />
1 kHz is still a fairly low frequency, so perhaps the stairsteps are just<br />
hard to see or they're being smoothed away. Next, set the signal generator to 15kHz, which is much closer to [[WikiPedia:Nyquist_frequency|Nyquist]].<br />
Now the sine wave is represented by less than three samples per cycle, and the digital waveform appears rather poor! Yet the analog output is still a perfect sine wave, exactly like the original.<br />
As we keep increasing frequency, all the way to 20kHz, the output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? It's a trick question; they were never there. Drawing a digital waveform as a stairstep was wrong to begin with.<br />
<br />
A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.<br />
A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.<br />
The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
The interesting and non-obvious bit is that [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]; it's a unique solution. If you sample a bandlimited signal and then convert it back, the original input is also the only possible output.<br />
A signal that differs even minutely from the original includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
As a result, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better (yes, even I) draw stairsteps even though they're<br />
technically wrong. It's a sort of one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is.<br />
<br />
Digital stairstep drawings are exactly the same thing. It's just a convenient drawing. The stairsteps aren't really there.<br />
<div style="clear:both"></div><br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. It doesn't matter if it's 24 bits or 16 bits or 8 bits.<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 is the same sine wave input, but we quantize it with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal, our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher. And that's the difference, the only difference, the number of bits makes.<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like?<br />
Those of you who have used analog recording equipment might think to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]], for those of you who are old enough to remember them, could reach as<br />
deep as 9 bits in perfect conditions. 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right; your old mix tapes were only about 6 bits<br />
deep if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. <br />
That's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
<div style="clear:both"></div><br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
We've been quantizing with [[Wikipedia:dither|dither]]. What is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simplest way to quantize a signal is to choose the digital<br />
amplitude value [[WikiPedia:Rounding|closest to the original analog amplitude]].<br />
Unfortunately, the exact noise that results from this simple<br />
quantization scheme depends somewhat on the input signal.<br />
It may be inconsistent, cause distortion, or be<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div>&nbsp;</center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
The signal generator has too much noise for this test so we produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
We see the sine wave on waveform display and output scope, and <br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible. Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. When we reenable dither, we clearly see our signal at 1/4 bit with a nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so it makes sense to choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Human hearing is [[WikiPedia:Equal-loudness_contour|most sensitive in the midrange from 2kHz to 4kHz]]; that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise, even though it often sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. However,<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
For the next test, we also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect.<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage; it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all this text spent on dither, the differences exist 100 decibels or more below [[WikiPedia:Full_scale|full scale]]. If the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
perhaps dither ''might'' be<br />
more important. At 16 bits it's mostly a wash. It's reasonable to treat<br />
dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. That said no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]? <br />
<br />
The input scope confirms a 1kHz square wave. The output scope shows... exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
We can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ squarewave(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
We remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]].<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
\ squarewave(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either; you'd have to sum an infinite number of harmonics to get the answer! However, we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]]. Only the first ten terms make it through, and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<div>&nbsp;</div><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it. For example, what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is:<br />
Nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
That's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We see that in this case that didn't happen, so<br />
it wasn't really the filter that added the ripples the first time<br />
through. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave it's still limited to the channel bandwidth. Remember that<br />
the stairstep representation is misleading. What we really have here are instantaneous sample points<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]]. The original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
That leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way, that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled or they just disappear.<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Like in [[Videos/A_Digital_Media_Primer_For_Geeks|_A Digital Media Primer for Geeks_]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around.<br />
<br />
Thus I encourage you to dig deeper and experiment. I chose my<br />
demos carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like, but let's face<br />
it: Sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is here at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. If you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14035Videos/Digital Show and Tell2013-02-26T10:59:36Z<p>Xiphmont: /* Bandlimitation and timing */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
First demo: We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before and we can see the analog sine wave on the input-side oscilloscope. The eMagic digitizes our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD. The spectrum of the digitized signal on the Thinkpad matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier. For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
When we look at the output signal that's been converted<br />
from digital back to analog, we see that it's exactly like the original sine wave. No stairsteps.<br />
<br />
1 kHz is still a fairly low frequency, so perhaps the stairsteps are just<br />
hard to see or they're being smoothed away. Next, set the signal generator to 15kHz, which is much closer to [[WikiPedia:Nyquist_frequency|Nyquist]].<br />
Now the sine wave is represented by less than three samples per cycle, and the digital waveform appears rather poor! Yet the analog output is still a perfect sine wave, exactly like the original.<br />
As we keep increasing frequency, all the way to 20kHz, the output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? It's a trick question; they were never there. Drawing a digital waveform as a stairstep was wrong to begin with.<br />
<br />
A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.<br />
A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.<br />
The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
The interesting and non-obvious bit is that [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]; it's a unique solution. If you sample a bandlimited signal and then convert it back, the original input is also the only possible output.<br />
A signal that differs even minutely from the original includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
As a result, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better (yes, even I) draw stairsteps even though they're<br />
technically wrong. It's a sort of one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is.<br />
<br />
Digital stairstep drawings are exactly the same thing. It's just a convenient drawing. The stairsteps aren't really there.<br />
<div style="clear:both"></div><br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. It doesn't matter if it's 24 bits or 16 bits or 8 bits.<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 is the same sine wave input, but we quantize it with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal, our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher. And that's the difference, the only difference, the number of bits makes.<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like?<br />
Those of you who have used analog recording equipment might think to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]], for those of you who are old enough to remember them, could reach as<br />
deep as 9 bits in perfect conditions. 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right; your old mix tapes were only about 6 bits<br />
deep if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. <br />
That's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
<div style="clear:both"></div><br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
We've been quantizing with [[Wikipedia:dither|dither]]. What is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simplest way to quantize a signal is to choose the digital<br />
amplitude value [[WikiPedia:Rounding|closest to the original analog amplitude]].<br />
Unfortunately, the exact noise that results from this simple<br />
quantization scheme depends somewhat on the input signal.<br />
It may be inconsistent, cause distortion, or be<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div>&nbsp;</center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
The signal generator has too much noise for this test so we produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
We see the sine wave on waveform display and output scope, and <br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible. Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. When we reenable dither, we clearly see our signal at 1/4 bit with a nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so it makes sense to choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Human hearing is [[WikiPedia:Equal-loudness_contour|most sensitive in the midrange from 2kHz to 4kHz]]; that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise, even though it often sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. However,<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
For the next test, we also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect.<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage; it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all this text spent on dither, the differences exist 100 decibels or more below [[WikiPedia:Full_scale|full scale]]. If the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
perhaps dither ''might'' be<br />
more important. At 16 bits it's mostly a wash. It's reasonable to treat<br />
dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. That said no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]? <br />
<br />
The input scope confirms a 1kHz square wave. The output scope shows... exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
We can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ squarewave(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
We remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]].<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
\ squarewave(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either; you'd have to sum an infinite number of harmonics to get the answer! However, we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]]. Only the first ten terms make it through, and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<div>&nbsp;</div><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it. For example, what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is:<br />
Nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
That's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We see that in this case that didn't happen, so<br />
it wasn't really the filter that added the ripples the first time<br />
through. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave it's still limited to the channel bandwidth. Remember that<br />
the stairstep representation is misleading. What we really have here are instantaneous sample points<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]]. The original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
That leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way, that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled or they just disappear.<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14034Videos/Digital Show and Tell2013-02-26T10:59:02Z<p>Xiphmont: /* Bandlimitation and timing */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
First demo: We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before and we can see the analog sine wave on the input-side oscilloscope. The eMagic digitizes our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD. The spectrum of the digitized signal on the Thinkpad matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier. For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
When we look at the output signal that's been converted<br />
from digital back to analog, we see that it's exactly like the original sine wave. No stairsteps.<br />
<br />
1 kHz is still a fairly low frequency, so perhaps the stairsteps are just<br />
hard to see or they're being smoothed away. Next, set the signal generator to 15kHz, which is much closer to [[WikiPedia:Nyquist_frequency|Nyquist]].<br />
Now the sine wave is represented by less than three samples per cycle, and the digital waveform appears rather poor! Yet the analog output is still a perfect sine wave, exactly like the original.<br />
As we keep increasing frequency, all the way to 20kHz, the output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? It's a trick question; they were never there. Drawing a digital waveform as a stairstep was wrong to begin with.<br />
<br />
A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.<br />
A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.<br />
The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
The interesting and non-obvious bit is that [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]; it's a unique solution. If you sample a bandlimited signal and then convert it back, the original input is also the only possible output.<br />
A signal that differs even minutely from the original includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
As a result, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better (yes, even I) draw stairsteps even though they're<br />
technically wrong. It's a sort of one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is.<br />
<br />
Digital stairstep drawings are exactly the same thing. It's just a convenient drawing. The stairsteps aren't really there.<br />
<div style="clear:both"></div><br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. It doesn't matter if it's 24 bits or 16 bits or 8 bits.<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 is the same sine wave input, but we quantize it with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal, our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher. And that's the difference, the only difference, the number of bits makes.<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like?<br />
Those of you who have used analog recording equipment might think to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]], for those of you who are old enough to remember them, could reach as<br />
deep as 9 bits in perfect conditions. 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right; your old mix tapes were only about 6 bits<br />
deep if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. <br />
That's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
<div style="clear:both"></div><br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
We've been quantizing with [[Wikipedia:dither|dither]]. What is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simplest way to quantize a signal is to choose the digital<br />
amplitude value [[WikiPedia:Rounding|closest to the original analog amplitude]].<br />
Unfortunately, the exact noise that results from this simple<br />
quantization scheme depends somewhat on the input signal.<br />
It may be inconsistent, cause distortion, or be<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div>&nbsp;</center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
The signal generator has too much noise for this test so we produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
We see the sine wave on waveform display and output scope, and <br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible. Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. When we reenable dither, we clearly see our signal at 1/4 bit with a nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so it makes sense to choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Human hearing is [[WikiPedia:Equal-loudness_contour|most sensitive in the midrange from 2kHz to 4kHz]]; that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise, even though it often sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. However,<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
For the next test, we also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect.<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage; it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all this text spent on dither, the differences exist 100 decibels or more below [[WikiPedia:Full_scale|full scale]]. If the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
perhaps dither ''might'' be<br />
more important. At 16 bits it's mostly a wash. It's reasonable to treat<br />
dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. That said no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]? <br />
<br />
The input scope confirms a 1kHz square wave. The output scope shows... exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
We can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ squarewave(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
We remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]].<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
\ squarewave(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either; you'd have to sum an infinite number of harmonics to get the answer! However, we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]]. Only the first ten terms make it through, and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it. For example, what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is:<br />
Nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
That's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We see that in this case that didn't happen, so<br />
it wasn't really the filter that added the ripples the first time<br />
through. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave it's still limited to the channel bandwidth. Remember that<br />
the stairstep representation is misleading. What we really have here are instantaneous sample points<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]]. The original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
That leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way, that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled or they just disappear.<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14031Videos/Digital Show and Tell2013-02-26T10:54:13Z<p>Xiphmont: /* Dither */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
First demo: We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before and we can see the analog sine wave on the input-side oscilloscope. The eMagic digitizes our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD. The spectrum of the digitized signal on the Thinkpad matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier. For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
When we look at the output signal that's been converted<br />
from digital back to analog, we see that it's exactly like the original sine wave. No stairsteps.<br />
<br />
1 kHz is still a fairly low frequency, so perhaps the stairsteps are just<br />
hard to see or they're being smoothed away. Next, set the signal generator to 15kHz, which is much closer to [[WikiPedia:Nyquist_frequency|Nyquist]].<br />
Now the sine wave is represented by less than three samples per cycle, and the digital waveform appears rather poor! Yet the analog output is still a perfect sine wave, exactly like the original.<br />
As we keep increasing frequency, all the way to 20kHz, the output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? It's a trick question; they were never there. Drawing a digital waveform as a stairstep was wrong to begin with.<br />
<br />
A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.<br />
A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.<br />
The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
The interesting and non-obvious bit is that [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]; it's a unique solution. If you sample a bandlimited signal and then convert it back, the original input is also the only possible output.<br />
A signal that differs even minutely from the original includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
As a result, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better (yes, even I) draw stairsteps even though they're<br />
technically wrong. It's a sort of one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is.<br />
<br />
Digital stairstep drawings are exactly the same thing. It's just a convenient drawing. The stairsteps aren't really there.<br />
<div style="clear:both"></div><br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. It doesn't matter if it's 24 bits or 16 bits or 8 bits.<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 is the same sine wave input, but we quantize it with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal, our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher. And that's the difference, the only difference, the number of bits makes.<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like?<br />
Those of you who have used analog recording equipment might think to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]], for those of you who are old enough to remember them, could reach as<br />
deep as 9 bits in perfect conditions. 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right; your old mix tapes were only about 6 bits<br />
deep if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. <br />
That's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
<div style="clear:both"></div><br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
We've been quantizing with [[Wikipedia:dither|dither]]. What is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simplest way to quantize a signal is to choose the digital<br />
amplitude value [[WikiPedia:Rounding|closest to the original analog amplitude]].<br />
Unfortunately, the exact noise that results from this simple<br />
quantization scheme depends somewhat on the input signal.<br />
It may be inconsistent, cause distortion, or be<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div>&nbsp;</center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
The signal generator has too much noise for this test so we produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
We see the sine wave on waveform display and output scope, and <br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible. Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. When we reenable dither, we clearly see our signal at 1/4 bit with a nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so it makes sense to choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Human hearing is most sensitive in the midrange from 2kHz to 4kHz; that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise, even though it often sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. However,<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
For the next test, we also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect.<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage; it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all this text spent on dither, the differences exist 100 decibels or more below [[WikiPedia:Full_scale|full scale]]. If the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
perhaps dither ''might'' be<br />
more important. At 16 bits it's mostly a wash. It's reasonable to treat<br />
dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. That said no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ squarewave(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a square wave.<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
\ squarewave(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]] and only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
<br />
<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14030Videos/Digital Show and Tell2013-02-26T10:43:38Z<p>Xiphmont: /* Bit-depth */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
First demo: We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before and we can see the analog sine wave on the input-side oscilloscope. The eMagic digitizes our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD. The spectrum of the digitized signal on the Thinkpad matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier. For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
When we look at the output signal that's been converted<br />
from digital back to analog, we see that it's exactly like the original sine wave. No stairsteps.<br />
<br />
1 kHz is still a fairly low frequency, so perhaps the stairsteps are just<br />
hard to see or they're being smoothed away. Next, set the signal generator to 15kHz, which is much closer to [[WikiPedia:Nyquist_frequency|Nyquist]].<br />
Now the sine wave is represented by less than three samples per cycle, and the digital waveform appears rather poor! Yet the analog output is still a perfect sine wave, exactly like the original.<br />
As we keep increasing frequency, all the way to 20kHz, the output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? It's a trick question; they were never there. Drawing a digital waveform as a stairstep was wrong to begin with.<br />
<br />
A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.<br />
A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.<br />
The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
The interesting and non-obvious bit is that [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]; it's a unique solution. If you sample a bandlimited signal and then convert it back, the original input is also the only possible output.<br />
A signal that differs even minutely from the original includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
As a result, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better (yes, even I) draw stairsteps even though they're<br />
technically wrong. It's a sort of one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is.<br />
<br />
Digital stairstep drawings are exactly the same thing. It's just a convenient drawing. The stairsteps aren't really there.<br />
<div style="clear:both"></div><br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. It doesn't matter if it's 24 bits or 16 bits or 8 bits.<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 is the same sine wave input, but we quantize it with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal, our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher. And that's the difference, the only difference, the number of bits makes.<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like?<br />
Those of you who have used analog recording equipment might think to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]], for those of you who are old enough to remember them, could reach as<br />
deep as 9 bits in perfect conditions. 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right; your old mix tapes were only about 6 bits<br />
deep if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. <br />
That's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
<div style="clear:both"></div><br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ squarewave(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a square wave.<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
\ squarewave(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]] and only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
<br />
<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14029Videos/Digital Show and Tell2013-02-26T10:43:09Z<p>Xiphmont: /* Stairsteps */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
First demo: We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before and we can see the analog sine wave on the input-side oscilloscope. The eMagic digitizes our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD. The spectrum of the digitized signal on the Thinkpad matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier. For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
When we look at the output signal that's been converted<br />
from digital back to analog, we see that it's exactly like the original sine wave. No stairsteps.<br />
<br />
1 kHz is still a fairly low frequency, so perhaps the stairsteps are just<br />
hard to see or they're being smoothed away. Next, set the signal generator to 15kHz, which is much closer to [[WikiPedia:Nyquist_frequency|Nyquist]].<br />
Now the sine wave is represented by less than three samples per cycle, and the digital waveform appears rather poor! Yet the analog output is still a perfect sine wave, exactly like the original.<br />
As we keep increasing frequency, all the way to 20kHz, the output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? It's a trick question; they were never there. Drawing a digital waveform as a stairstep was wrong to begin with.<br />
<br />
A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.<br />
A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.<br />
The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
The interesting and non-obvious bit is that [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]; it's a unique solution. If you sample a bandlimited signal and then convert it back, the original input is also the only possible output.<br />
A signal that differs even minutely from the original includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
As a result, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better (yes, even I) draw stairsteps even though they're<br />
technically wrong. It's a sort of one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is.<br />
<br />
Digital stairstep drawings are exactly the same thing. It's just a convenient drawing. The stairsteps aren't really there.<br />
<div style="clear:both"></div><br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. It doesn't matter if it's 24 bits or 16 bits or 8 bits.<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 is the same sine wave input, but we quantize it with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal, our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher. And that's the difference, the only difference, the number of bits makes.<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like?<br />
Those of you who have used analog recording equipment might think to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]], for those of you who are old enough to remember them, could reach as<br />
deep as 9 bits in perfect conditions. 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right; your old mix tapes were only about 6 bits<br />
deep if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. <br />
That's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ squarewave(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a square wave.<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
\ squarewave(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]] and only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
<br />
<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14028Videos/Digital Show and Tell2013-02-26T10:42:16Z<p>Xiphmont: ensmallen some pics</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|200px|right]]<br />
[[Image:Dsat 007.png|200px|right]]<br />
First demo: We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before and we can see the analog sine wave on the input-side oscilloscope. The eMagic digitizes our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD. The spectrum of the digitized signal on the Thinkpad matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier. For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
When we look at the output signal that's been converted<br />
from digital back to analog, we see that it's exactly like the original sine wave. No stairsteps.<br />
<br />
1 kHz is still a fairly low frequency, so perhaps the stairsteps are just<br />
hard to see or they're being smoothed away. Next, set the signal generator to 15kHz, which is much closer to [[WikiPedia:Nyquist_frequency|Nyquist]].<br />
Now the sine wave is represented by less than three samples per cycle, and the digital waveform appears rather poor! Yet the analog output is still a perfect sine wave, exactly like the original.<br />
As we keep increasing frequency, all the way to 20kHz, the output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? It's a trick question; they were never there. Drawing a digital waveform as a stairstep was wrong to begin with.<br />
<br />
A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.<br />
A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.<br />
The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
[[Image:Dsat 008.png|200px|right]]<br />
The interesting and non-obvious bit is that [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]; it's a unique solution. If you sample a bandlimited signal and then convert it back, the original input is also the only possible output.<br />
A signal that differs even minutely from the original includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
As a result, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better (yes, even I) draw stairsteps even though they're<br />
technically wrong. It's a sort of one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is.<br />
<br />
Digital stairstep drawings are exactly the same thing. It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. It doesn't matter if it's 24 bits or 16 bits or 8 bits.<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 is the same sine wave input, but we quantize it with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal, our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher. And that's the difference, the only difference, the number of bits makes.<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like?<br />
Those of you who have used analog recording equipment might think to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]], for those of you who are old enough to remember them, could reach as<br />
deep as 9 bits in perfect conditions. 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right; your old mix tapes were only about 6 bits<br />
deep if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. <br />
That's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ squarewave(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a square wave.<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
\ squarewave(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]] and only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
<br />
<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14027Videos/Digital Show and Tell2013-02-26T10:40:10Z<p>Xiphmont: /* Bit-depth */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
First demo: We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before and we can see the analog sine wave on the input-side oscilloscope. The eMagic digitizes our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD. The spectrum of the digitized signal on the Thinkpad matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier. For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
When we look at the output signal that's been converted<br />
from digital back to analog, we see that it's exactly like the original sine wave. No stairsteps.<br />
<br />
1 kHz is still a fairly low frequency, so perhaps the stairsteps are just<br />
hard to see or they're being smoothed away. Next, set the signal generator to 15kHz, which is much closer to [[WikiPedia:Nyquist_frequency|Nyquist]].<br />
Now the sine wave is represented by less than three samples per cycle, and the digital waveform appears rather poor! Yet the analog output is still a perfect sine wave, exactly like the original.<br />
As we keep increasing frequency, all the way to 20kHz, the output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? It's a trick question; they were never there. Drawing a digital waveform as a stairstep was wrong to begin with.<br />
<br />
A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.<br />
A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.<br />
The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
The interesting and non-obvious bit is that [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]; it's a unique solution. If you sample a bandlimited signal and then convert it back, the original input is also the only possible output.<br />
A signal that differs even minutely from the original includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
As a result, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better (yes, even I) draw stairsteps even though they're<br />
technically wrong. It's a sort of one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is.<br />
<br />
Digital stairstep drawings are exactly the same thing. It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. It doesn't matter if it's 24 bits or 16 bits or 8 bits.<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 is the same sine wave input, but we quantize it with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal, our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher. And that's the difference, the only difference, the number of bits makes.<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like?<br />
Those of you who have used analog recording equipment might think to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]], for those of you who are old enough to remember them, could reach as<br />
deep as 9 bits in perfect conditions. 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right; your old mix tapes were only about 6 bits<br />
deep if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. <br />
That's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ squarewave(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a square wave.<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
\ squarewave(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]] and only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
<br />
<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14026Videos/Digital Show and Tell2013-02-26T10:36:50Z<p>Xiphmont: /* Stairsteps */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
First demo: We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before and we can see the analog sine wave on the input-side oscilloscope. The eMagic digitizes our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD. The spectrum of the digitized signal on the Thinkpad matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier. For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
When we look at the output signal that's been converted<br />
from digital back to analog, we see that it's exactly like the original sine wave. No stairsteps.<br />
<br />
1 kHz is still a fairly low frequency, so perhaps the stairsteps are just<br />
hard to see or they're being smoothed away. Next, set the signal generator to 15kHz, which is much closer to [[WikiPedia:Nyquist_frequency|Nyquist]].<br />
Now the sine wave is represented by less than three samples per cycle, and the digital waveform appears rather poor! Yet the analog output is still a perfect sine wave, exactly like the original.<br />
As we keep increasing frequency, all the way to 20kHz, the output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? It's a trick question; they were never there. Drawing a digital waveform as a stairstep was wrong to begin with.<br />
<br />
A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.<br />
A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.<br />
The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
The interesting and non-obvious bit is that [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]; it's a unique solution. If you sample a bandlimited signal and then convert it back, the original input is also the only possible output.<br />
A signal that differs even minutely from the original includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
As a result, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better (yes, even I) draw stairsteps even though they're<br />
technically wrong. It's a sort of one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is.<br />
<br />
Digital stairstep drawings are exactly the same thing. It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ squarewave(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a square wave.<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
\ squarewave(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]] and only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
<br />
<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14025Videos/Digital Show and Tell2013-02-26T10:35:39Z<p>Xiphmont: /* Stairsteps */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
First demo: We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before and we can see the analog sine wave on the input-side oscilloscope. The eMagic digitizes our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD. The spectrum of the digitized signal on the Thinkpad matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier. For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
When we look at the output signal that's been converted<br />
from digital back to analog, we see that it's exactly like the original sine wave. No stairsteps.<br />
<br />
1 kHz is still a fairly low frequency, so perhaps the stairsteps are just<br />
hard to see or they're being smoothed away. Next, set the signal generator to 15kHz, which is much closer to [[WikiPedia:Nyquist_frequency|Nyquist]].<br />
Now the sine wave is represented by less than three samples per cycle, and the digital waveform appears rather poor! Yet the analog output is still a perfect sine wave, exactly like the original.<br />
As we keep increasing frequency, all the way to 20kHz, the output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? It's a trick question; they were never there. Drawing a digital waveform as a stairstep was wrong to begin with.<br />
<br />
A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.<br />
A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.<br />
The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
The interesting and non-obvious bit is that[[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]; it's a unique solution. If you sample a bandlimited signal and then convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
Before you say, "I can draw a different signal that passes through those points", if it differs even<br />
minutely from the original, it includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
As a result, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better (yes, even I) draw stairsteps even though they're<br />
technically wrong. It's a sort of one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is.<br />
<br />
Digital stairstep drawings are exactly the same thing. It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ squarewave(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a square wave.<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
\ squarewave(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]] and only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
<br />
<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14024Videos/Digital Show and Tell2013-02-26T10:30:51Z<p>Xiphmont: /* Stairsteps */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
First demo: We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before and we can see the analog sine wave on the input-side oscilloscope. The eMagic digitizes our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD. The spectrum of the digitized signal on the Thinkpad matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier. For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
When we look at the output signal that's been converted<br />
from digital back to analog, we see that it's exactly like the original sine wave. No stairsteps.<br />
<br />
1 kHz is still a fairly low frequency, so perhaps the stairsteps are just<br />
hard to see or they're being smoothed away. Next, set the signal generator to 15kHz, which is much closer to [[WikiPedia:Nyquist_frequency|Nyquist]].<br />
Now the sine wave is represented by less than three samples per cycle, and the digital waveform appears rather poor! Yet the analog output is still a perfect sine wave, exactly like the original.<br />
<br />
&ldquo;Let's keep going up.&rdquo;<br />
<br />
&ldquo;16kHz.... 17kHz... 18kHz... 19kHz...&rdquo;<br />
<br />
&ldquo;20kHz. Welcome to the upper limits of human hearing. The output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.&rdquo;<br />
<br />
&ldquo;So where'd the stairsteps go? Don't answer, it's a trick question. They were never there.&rdquo;<br />
<br />
&ldquo;Drawing a digital waveform as a stairstep was wrong to begin with.&rdquo;<br />
<br />
&ldquo;Why? A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.&rdquo;<br />
<br />
&ldquo;A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.&rdquo;<br />
<br />
&ldquo;The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.&rdquo;<br />
<br />
&ldquo;Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's a unique solution. So if you sample a bandlimited signal and then convert it back, the original input is also the only possible output.&rdquo;<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
&ldquo;And before you say, "oh, I can draw a different signal that passes through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.&rdquo;<br />
<br />
&ldquo;So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.&rdquo;<br />
<br />
&ldquo;First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.&rdquo;<br />
<br />
&ldquo;So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.&rdquo;<br />
<br />
&ldquo;Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].&rdquo;<br />
<br />
&ldquo;Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.&rdquo;<br />
<br />
&ldquo;It's just a convenient drawing. The stairsteps aren't really there.&rdquo;<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ squarewave(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a square wave.<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
\ squarewave(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]] and only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
<br />
<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14022Videos/Digital Show and Tell2013-02-26T10:25:39Z<p>Xiphmont: /* Veritas ex machina */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
If we pretend for a moment that we have no idea how digital signals really<br />
behave, then it doesn't make sense for us to use digital test<br />
equipment. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
&ldquo;OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.&rdquo;<br />
<br />
&ldquo;The signal generator is set to produce a 1kHz sine wave just like<br />
before.&rdquo;<br />
<br />
&ldquo;We can see our analog sine wave on our input-side oscilloscope.&rdquo;<br />
<br />
&ldquo;We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.&rdquo;<br />
<br />
&ldquo;The spectrum of the digitized signal matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.&rdquo;<br />
<br />
&ldquo;For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.&rdquo;<br />
<br />
&ldquo;And when we look at the output signal that's been converted<br />
from digital back to analog, we see...&rdquo;<br />
<br />
&ldquo;It's exactly like the original sine wave. No stairsteps.&rdquo;<br />
<br />
&ldquo;OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.&rdquo;<br />
<br />
&ldquo;Now the sine wave is represented by less than three samples per cycle, and... the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output... is still a perfect sine wave, exactly like the original.&rdquo;<br />
<br />
&ldquo;Let's keep going up.&rdquo;<br />
<br />
&ldquo;16kHz.... 17kHz... 18kHz... 19kHz...&rdquo;<br />
<br />
&ldquo;20kHz. Welcome to the upper limits of human hearing. The output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.&rdquo;<br />
<br />
&ldquo;So where'd the stairsteps go? Don't answer, it's a trick question. They were never there.&rdquo;<br />
<br />
&ldquo;Drawing a digital waveform as a stairstep was wrong to begin with.&rdquo;<br />
<br />
&ldquo;Why? A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.&rdquo;<br />
<br />
&ldquo;A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.&rdquo;<br />
<br />
&ldquo;The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.&rdquo;<br />
<br />
&ldquo;Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's a unique solution. So if you sample a bandlimited signal and then convert it back, the original input is also the only possible output.&rdquo;<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
&ldquo;And before you say, "oh, I can draw a different signal that passes through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.&rdquo;<br />
<br />
&ldquo;So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.&rdquo;<br />
<br />
&ldquo;First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.&rdquo;<br />
<br />
&ldquo;So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.&rdquo;<br />
<br />
&ldquo;Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].&rdquo;<br />
<br />
&ldquo;Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.&rdquo;<br />
<br />
&ldquo;It's just a convenient drawing. The stairsteps aren't really there.&rdquo;<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]] and only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
<br />
<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14021Videos/Digital Show and Tell2013-02-26T10:23:34Z<p>Xiphmont: </p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&ldquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&ldquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&ldquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &rdquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to a ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
&ldquo;OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.&rdquo;<br />
<br />
&ldquo;The signal generator is set to produce a 1kHz sine wave just like<br />
before.&rdquo;<br />
<br />
&ldquo;We can see our analog sine wave on our input-side oscilloscope.&rdquo;<br />
<br />
&ldquo;We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.&rdquo;<br />
<br />
&ldquo;The spectrum of the digitized signal matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.&rdquo;<br />
<br />
&ldquo;For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.&rdquo;<br />
<br />
&ldquo;And when we look at the output signal that's been converted<br />
from digital back to analog, we see...&rdquo;<br />
<br />
&ldquo;It's exactly like the original sine wave. No stairsteps.&rdquo;<br />
<br />
&ldquo;OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.&rdquo;<br />
<br />
&ldquo;Now the sine wave is represented by less than three samples per cycle, and... the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output... is still a perfect sine wave, exactly like the original.&rdquo;<br />
<br />
&ldquo;Let's keep going up.&rdquo;<br />
<br />
&ldquo;16kHz.... 17kHz... 18kHz... 19kHz...&rdquo;<br />
<br />
&ldquo;20kHz. Welcome to the upper limits of human hearing. The output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.&rdquo;<br />
<br />
&ldquo;So where'd the stairsteps go? Don't answer, it's a trick question. They were never there.&rdquo;<br />
<br />
&ldquo;Drawing a digital waveform as a stairstep was wrong to begin with.&rdquo;<br />
<br />
&ldquo;Why? A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.&rdquo;<br />
<br />
&ldquo;A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.&rdquo;<br />
<br />
&ldquo;The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.&rdquo;<br />
<br />
&ldquo;Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's a unique solution. So if you sample a bandlimited signal and then convert it back, the original input is also the only possible output.&rdquo;<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
&ldquo;And before you say, "oh, I can draw a different signal that passes through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.&rdquo;<br />
<br />
&ldquo;So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.&rdquo;<br />
<br />
&ldquo;First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.&rdquo;<br />
<br />
&ldquo;So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.&rdquo;<br />
<br />
&ldquo;Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].&rdquo;<br />
<br />
&ldquo;Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.&rdquo;<br />
<br />
&ldquo;It's just a convenient drawing. The stairsteps aren't really there.&rdquo;<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]] and only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
<br />
<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14020Videos/Digital Show and Tell2013-02-26T10:22:38Z<p>Xiphmont: /* Veritas ex machina */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&rdquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&rdquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&rdquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &ldquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
We need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978.<br />
<br />
We'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and best analog scopes made.<br />
<br />
Finally, we'll inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but the specs are still quite good.<br />
<br />
We start with the signal generator set to output a 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
This doesn't matter to the demos, but it's good to take notice of it now to avoid confusion later.<br />
<br />
For digital conversion, we use a boring, consumer-grade, eMagic USB1<br />
audio device. It's more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
You may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to a ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
&ldquo;OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.&rdquo;<br />
<br />
&ldquo;The signal generator is set to produce a 1kHz sine wave just like<br />
before.&rdquo;<br />
<br />
&ldquo;We can see our analog sine wave on our input-side oscilloscope.&rdquo;<br />
<br />
&ldquo;We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.&rdquo;<br />
<br />
&ldquo;The spectrum of the digitized signal matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.&rdquo;<br />
<br />
&ldquo;For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.&rdquo;<br />
<br />
&ldquo;And when we look at the output signal that's been converted<br />
from digital back to analog, we see...&rdquo;<br />
<br />
&ldquo;It's exactly like the original sine wave. No stairsteps.&rdquo;<br />
<br />
&ldquo;OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.&rdquo;<br />
<br />
&ldquo;Now the sine wave is represented by less than three samples per cycle, and... the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output... is still a perfect sine wave, exactly like the original.&rdquo;<br />
<br />
&ldquo;Let's keep going up.&rdquo;<br />
<br />
&ldquo;16kHz.... 17kHz... 18kHz... 19kHz...&rdquo;<br />
<br />
&ldquo;20kHz. Welcome to the upper limits of human hearing. The output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.&rdquo;<br />
<br />
&ldquo;So where'd the stairsteps go? Don't answer, it's a trick question. They were never there.&rdquo;<br />
<br />
&ldquo;Drawing a digital waveform as a stairstep was wrong to begin with.&rdquo;<br />
<br />
&ldquo;Why? A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.&rdquo;<br />
<br />
&ldquo;A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.&rdquo;<br />
<br />
&ldquo;The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.&rdquo;<br />
<br />
&ldquo;Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's a unique solution. So if you sample a bandlimited signal and then convert it back, the original input is also the only possible output.&rdquo;<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
&ldquo;And before you say, "oh, I can draw a different signal that passes through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.&rdquo;<br />
<br />
&ldquo;So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.&rdquo;<br />
<br />
&ldquo;First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.&rdquo;<br />
<br />
&ldquo;So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.&rdquo;<br />
<br />
&ldquo;Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].&rdquo;<br />
<br />
&ldquo;Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.&rdquo;<br />
<br />
&ldquo;It's just a convenient drawing. The stairsteps aren't really there.&rdquo;<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_016.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[image:Dsat_013.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]] and only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
<br />
<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14016Videos/Digital Show and Tell2013-02-26T10:17:05Z<p>Xiphmont: </p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
&rdquo;Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
&rdquo;A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
&rdquo;Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals. &ldquo;<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
&ldquo;OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.&rdquo;<br />
<br />
&ldquo;The signal generator is set to produce a 1kHz sine wave just like<br />
before.&rdquo;<br />
<br />
&ldquo;We can see our analog sine wave on our input-side oscilloscope.&rdquo;<br />
<br />
&ldquo;We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.&rdquo;<br />
<br />
&ldquo;The spectrum of the digitized signal matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.&rdquo;<br />
<br />
&ldquo;For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.&rdquo;<br />
<br />
&ldquo;And when we look at the output signal that's been converted<br />
from digital back to analog, we see...&rdquo;<br />
<br />
&ldquo;It's exactly like the original sine wave. No stairsteps.&rdquo;<br />
<br />
&ldquo;OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.&rdquo;<br />
<br />
&ldquo;Now the sine wave is represented by less than three samples per cycle, and... the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output... is still a perfect sine wave, exactly like the original.&rdquo;<br />
<br />
&ldquo;Let's keep going up.&rdquo;<br />
<br />
&ldquo;16kHz.... 17kHz... 18kHz... 19kHz...&rdquo;<br />
<br />
&ldquo;20kHz. Welcome to the upper limits of human hearing. The output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.&rdquo;<br />
<br />
&ldquo;So where'd the stairsteps go? Don't answer, it's a trick question. They were never there.&rdquo;<br />
<br />
&ldquo;Drawing a digital waveform as a stairstep was wrong to begin with.&rdquo;<br />
<br />
&ldquo;Why? A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.&rdquo;<br />
<br />
&ldquo;A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.&rdquo;<br />
<br />
&ldquo;The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.&rdquo;<br />
<br />
&ldquo;Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's a unique solution. So if you sample a bandlimited signal and then convert it back, the original input is also the only possible output.&rdquo;<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
&ldquo;And before you say, "oh, I can draw a different signal that passes through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.&rdquo;<br />
<br />
&ldquo;So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.&rdquo;<br />
<br />
&ldquo;First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.&rdquo;<br />
<br />
&ldquo;So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.&rdquo;<br />
<br />
&ldquo;Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].&rdquo;<br />
<br />
&ldquo;Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.&rdquo;<br />
<br />
&ldquo;It's just a convenient drawing. The stairsteps aren't really there.&rdquo;<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14015Videos/Digital Show and Tell2013-02-26T10:15:21Z<p>Xiphmont: /* Using Gtk-bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
&ldquo;OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.&rdquo;<br />
<br />
&ldquo;The signal generator is set to produce a 1kHz sine wave just like<br />
before.&rdquo;<br />
<br />
&ldquo;We can see our analog sine wave on our input-side oscilloscope.&rdquo;<br />
<br />
&ldquo;We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.&rdquo;<br />
<br />
&ldquo;The spectrum of the digitized signal matches what we saw earlier and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.&rdquo;<br />
<br />
&ldquo;For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.&rdquo;<br />
<br />
&ldquo;And when we look at the output signal that's been converted<br />
from digital back to analog, we see...&rdquo;<br />
<br />
&ldquo;It's exactly like the original sine wave. No stairsteps.&rdquo;<br />
<br />
&ldquo;OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.&rdquo;<br />
<br />
&ldquo;Now the sine wave is represented by less than three samples per cycle, and... the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output... is still a perfect sine wave, exactly like the original.&rdquo;<br />
<br />
&ldquo;Let's keep going up.&rdquo;<br />
<br />
&ldquo;16kHz.... 17kHz... 18kHz... 19kHz...&rdquo;<br />
<br />
&ldquo;20kHz. Welcome to the upper limits of human hearing. The output waveform is still perfect. No jagged edges, no dropoff, no stairsteps.&rdquo;<br />
<br />
&ldquo;So where'd the stairsteps go? Don't answer, it's a trick question. They were never there.&rdquo;<br />
<br />
&ldquo;Drawing a digital waveform as a stairstep was wrong to begin with.&rdquo;<br />
<br />
&ldquo;Why? A stairstep is a continuous-time function. It's jagged, and it's piecewise, but it has a defined value at every point in time.&rdquo;<br />
<br />
&ldquo;A sampled signal is entirely different. It's discrete-time; it's only got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A discrete-time signal is properly drawn as a lollipop graph.&rdquo;<br />
<br />
&ldquo;The continuous, analog counterpart of a digital signal passes smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.&rdquo;<br />
<br />
&ldquo;Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's a unique solution. So if you sample a bandlimited signal and then convert it back, the original input is also the only possible output.&rdquo;<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
&ldquo;And before you say, "oh, I can draw a different signal that passes through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond Nyquist, breaks the bandlimiting requirement and isn't a valid solution.&rdquo;<br />
<br />
&ldquo;So how did everyone get confused and start thinking of digital signals as stairsteps? I can think of two good reasons.&rdquo;<br />
<br />
&ldquo;First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.&rdquo;<br />
<br />
&ldquo;So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.&rdquo;<br />
<br />
&ldquo;Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].&rdquo;<br />
<br />
&ldquo;Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.&rdquo;<br />
<br />
&ldquo;It's just a convenient drawing. The stairsteps aren't really there.&rdquo;<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now let's look at something a bit more complex. What should we expect to happen when I change the input to a [[WikiPedia:Square_wave|square wave]]... The input scope confirms our 1kHz square wave. The output scope shows… Exactly what it should.<br />
<br />
What is a square wave really? <br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very accurate/useful.) <br />
</div></center><br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizing the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration square wave without any harmonics landing in the transition band. The input is read from the audio device, passed through this sharper filter, and then forwarded to the outputs.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'square wave' (this is not quite equivalent to a bandlimited analog square wave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': as in panel 8, generate a 'perfect' synthetic 'square wave'. However, the slider now allows us to shift the sample alignment of the second channel with respect to the first, instead of shifting both channels. This allows us the trigger/lock the scope timing to the channel 1 waveform so we can see the fractional sample movement and alignment of the waveform on channel 2. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': not used in the video; The audio device is configured to 24-bit input/output. The user may produce one of a range of test signals that are output to both the external applications and the audio device on the first channel. The input on the second channel is passed-through to the applications and audio device outputs unchanged. The first channel input is unused unless 'two input mode' is selected. When two input mode is selected, both input channels are read and the data sent to the external applications. Generated test signals are sent only to the audio hardware (on the first channel). This combination of test signals and input modes allows self-references frequency response, phase, noise, distortion and crosstalk testing of a given audio device.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDDD;border-color:#CCCCCC;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14006Videos/Digital Show and Tell2013-02-26T10:01:40Z<p>Xiphmont: /* Using Gtk-bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*In modern web browsers you can program audio synthesizers directly in javascript. Use the two square wave formulas to get a square wave out of [http://js.do/blog/sound-waves-with-javascript/ this page]. (Note: The scope is not very useful.) <br />
</div></center><br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizating the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration squarewave without any harmonics landing in the transition band. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': when selected, generate a synthetic 'squarewave' (this is not quite equivalent to a bandlimited analog squarewave; the harmonic amplitudes are a bit different) that when aligned with the sampling phase just right gives the appearance of having infinite rise and fall time. The slider allows us to shift the waveform sample alignment back and forth by +/- one sample to reveal that the underlying signal is still band-limited.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14004Videos/Digital Show and Tell2013-02-26T09:56:54Z<p>Xiphmont: /* Using Gtk-bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizating the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': applies a sharper antialiasing (lowpass) filter than is likely to be built into the sound-card hardware (as there's generally no reason to use a filter quite this sharp in practice). The very sharp filter allows us to bandpass the demonstration squarewave without any harmonics landing in the transition band. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14003Videos/Digital Show and Tell2013-02-26T09:53:49Z<p>Xiphmont: /* Using Gtk-bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': allows the user to play with the power of the dithering noise applied before quantizating the sine wave. Shaped or flat dither are available. The sine wave may also be modulated with a varying amplitude to highlight correlations between the input and the resulting quantization noise. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14002Videos/Digital Show and Tell2013-02-26T09:50:58Z<p>Xiphmont: /* Using Gtk-bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': generates a 16-bit sine wave, optionally quantized using dither. The user may additionally select a flat or a shaped dither. The 'notch and gain' button applies a notch filter to the resulting signal, and boosts the gain of the remaining noise so that it's easily audible. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14001Videos/Digital Show and Tell2013-02-26T09:47:40Z<p>Xiphmont: /* Using Gtk-bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded. Note that the slider sets the peak amplitude, not the peak-to-peak amplitude.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=14000Videos/Digital Show and Tell2013-02-26T09:45:50Z<p>Xiphmont: /* Using Gtk-bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' discards the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': gtk-bounce generates a 16-bit sine wave of the selected amplitude, optionally with dither, and forwards the resulting signal to the outputs. The audio input from the audio device is discarded.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=13999Videos/Digital Show and Tell2013-02-26T09:42:41Z<p>Xiphmont: /* Using Gtk-bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' disables the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=13998Videos/Digital Show and Tell2013-02-26T09:40:34Z<p>Xiphmont: /* Using Gtk-bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': Both channels are re-quantized to the selected bit depth. Requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': 'generate sine wave' disables the audio inputs and instead internally generates a sine wave at 32 bit precision, which is then quantized to the selected bit depth, optionally with dither. The resulting signal is then forwarded to the output. <br />
<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': <br />
<div style="clear: both"><&nbsp;/div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=13997Videos/Digital Show and Tell2013-02-26T09:34:55Z<p>Xiphmont: /* Using Gtk-bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': <br />
<div style="clear: both">&nbsp;</div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': <br />
<div style="clear: both"><&nbsp;/div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=13996Videos/Digital Show and Tell2013-02-26T09:34:06Z<p>Xiphmont: /* GTK-Bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
==== Starting Gtk-bounce ====<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
==== Using Gtk-bounce ====<br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': <br />
<div style="clear: both"></div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=13995Videos/Digital Show and Tell2013-02-26T09:32:47Z<p>Xiphmont: /* GTK-Bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:Sound_power|power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"[http://music.lousyrobot.com/track/andy-warhol-is-gone Andy Warhol Is Gone]", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': Both channels are forwarded to the outputs, however the user may select the bit depth of each channel independently. When the sound card is running in 16 bit mode and 16-bit depth is selected, the data is untouched. requantization to a lower bit depth is performed with a flat triangle dither.<br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': <br />
<div style="clear: both"></div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=13992Videos/Digital Show and Tell2013-02-26T09:28:14Z<p>Xiphmont: /* GTK-Bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:power|Sound_power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"Andy Warhol Is Gone", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
<br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel1.png|700px|center]]<br />
* '''Panel 1''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel2.png|700px|center]]<br />
* '''Panel 2''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel3.png|700px|center]]<br />
* '''Panel 3''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel4.png|700px|center]]<br />
* '''Panel 4''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel5.png|700px|center]]<br />
* '''Panel 5''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel6.png|700px|center]]<br />
* '''Panel 6''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel7.png|700px|center]]<br />
* '''Panel 7''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel8.png|700px|center]]<br />
* '''Panel 8''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel9.png|700px|center]]<br />
* '''Panel 9''': <br />
<div style="clear: both"></div><br />
<br />
[[Image:Dsat-panel10.png|700px|center]]<br />
* '''Panel 10''': <br />
<div style="clear: both"></div><br />
<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=File:Dsat-panel10.png&diff=13991File:Dsat-panel10.png2013-02-26T09:24:37Z<p>Xiphmont: gtk-bounce panel 10 screenshot</p>
<hr />
<div>gtk-bounce panel 10 screenshot</div>Xiphmonthttps://wiki.xiph.org/index.php?title=File:Dsat-panel9.png&diff=13990File:Dsat-panel9.png2013-02-26T09:24:17Z<p>Xiphmont: gtk-bounce panel 9 screenshot</p>
<hr />
<div>gtk-bounce panel 9 screenshot</div>Xiphmonthttps://wiki.xiph.org/index.php?title=File:Dsat-panel8.png&diff=13989File:Dsat-panel8.png2013-02-26T09:24:01Z<p>Xiphmont: gtk-bounce panel 8 screenshot</p>
<hr />
<div>gtk-bounce panel 8 screenshot</div>Xiphmonthttps://wiki.xiph.org/index.php?title=File:Dsat-panel7.png&diff=13988File:Dsat-panel7.png2013-02-26T09:23:41Z<p>Xiphmont: gtk-bounce panel 7 screenshot</p>
<hr />
<div>gtk-bounce panel 7 screenshot</div>Xiphmonthttps://wiki.xiph.org/index.php?title=File:Dsat-panel6.png&diff=13987File:Dsat-panel6.png2013-02-26T09:23:11Z<p>Xiphmont: gtk-bounce panel 6 screenshot</p>
<hr />
<div>gtk-bounce panel 6 screenshot</div>Xiphmonthttps://wiki.xiph.org/index.php?title=File:Dsat-panel5.png&diff=13986File:Dsat-panel5.png2013-02-26T09:22:54Z<p>Xiphmont: gtk-bounce panel 5 screenshot</p>
<hr />
<div>gtk-bounce panel 5 screenshot</div>Xiphmonthttps://wiki.xiph.org/index.php?title=File:Dsat-panel4.png&diff=13985File:Dsat-panel4.png2013-02-26T09:22:36Z<p>Xiphmont: gtk-bounce panel 4 screenshot</p>
<hr />
<div>gtk-bounce panel 4 screenshot</div>Xiphmonthttps://wiki.xiph.org/index.php?title=File:Dsat-panel3.png&diff=13984File:Dsat-panel3.png2013-02-26T09:22:18Z<p>Xiphmont: gtk-bounce panel 3 screenshot</p>
<hr />
<div>gtk-bounce panel 3 screenshot</div>Xiphmonthttps://wiki.xiph.org/index.php?title=File:Dsat-panel2.png&diff=13983File:Dsat-panel2.png2013-02-26T09:21:59Z<p>Xiphmont: gtk-bounce panel 2 screenshot</p>
<hr />
<div>gtk-bounce panel 2 screenshot</div>Xiphmonthttps://wiki.xiph.org/index.php?title=File:Dsat-panel1.png&diff=13982File:Dsat-panel1.png2013-02-26T09:21:42Z<p>Xiphmont: gtk-bounce panel 1 screenshot</p>
<hr />
<div>gtk-bounce panel 1 screenshot</div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=13981Videos/Digital Show and Tell2013-02-26T09:18:51Z<p>Xiphmont: /* GTK-Bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:power|Sound_power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"Andy Warhol Is Gone", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
[[Image:Dsat-panel0.png|700px|center]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both"></div><br />
<br />
* Panel 1: <br />
<br />
* Panel 2: <br />
<br />
* Panel 3: <br />
<br />
* Panel 4: <br />
<br />
* Panel 5: <br />
<br />
* Panel 6: <br />
<br />
* Panel 7: <br />
<br />
* Panel 8: <br />
<br />
* Panel 9: <br />
<br />
* Panel 10:<br />
</div></center><br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=13980Videos/Digital Show and Tell2013-02-26T09:17:05Z<p>Xiphmont: /* GTK-Bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:power|Sound_power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"Andy Warhol Is Gone", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
[[Image:Dsat-panel0.png|600px|right]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both"></div><br />
<br />
* Panel 1: <br />
<br />
* Panel 2: <br />
<br />
* Panel 3: <br />
<br />
* Panel 4: <br />
<br />
* Panel 5: <br />
<br />
* Panel 6: <br />
<br />
* Panel 7: <br />
<br />
* Panel 8: <br />
<br />
* Panel 9: <br />
<br />
* Panel 10:<br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmonthttps://wiki.xiph.org/index.php?title=File:Dsat-panel0.png&diff=13979File:Dsat-panel0.png2013-02-26T09:16:30Z<p>Xiphmont: uploaded a new version of &quot;File:Dsat-panel0.png&quot;: no need to pre-downscale</p>
<hr />
<div>screenshot of gtk-bounce's panel 0</div>Xiphmonthttps://wiki.xiph.org/index.php?title=Videos/Digital_Show_and_Tell&diff=13978Videos/Digital Show and Tell2013-02-26T09:14:57Z<p>Xiphmont: /* GTK-Bounce */</p>
<hr />
<div><small>''Wiki edition''</small><br />
[[Image:dsat_001.jpg|400px|right]]<br />
<br />
Continuing in the "firehose" tradition of [[Videos/A_Digital_Media_Primer_For_Geeks|Episode 01]], Xiph.Org's second video on digital media explores multiple facets of digital audio signals and how they ''really'' behave in the real world.<br />
<br />
Demonstrations of sampling, quantization, bit-depth, and dither explore digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment, just in case we can't trust those newfangled digital gizmos. You can download the source code for each demo and try it all for yourself!<br />
<br/><br/><br/><br />
<center><font size="+2">[http://www.xiph.org/video/vid2.shtml Download or Watch online]</font></center><br />
<br style="clear:both;"/><br />
Supported players: [http://www.videolan.org/vlc/ VLC 1.1+], [https://www.mozilla.com/en-US/firefox/ Firefox ], [http://www.chromium.org/Home Chrome ], [http://www.opera.com/ Opera]. Or see [http://www.webmproject.org/users/ other WebM] or [[TheoraSoftwarePlayers|other Theora]] players.<br />
<br />
If you're having trouble with playback in a modern browser or player, please visit our [[Playback_Troubleshooting|playback troubleshooting and discussion]] page.<br />
<br/><br />
<hr/><br />
<br/><br/><br/><br />
[[Image:Xiph_ep02_test.png|400px|right]]<br />
<br />
Hi, I'm Monty Montgomery from [http://www.redhat.com/ Red Hat] and [http://xiph.org/ Xiph.Org].<br />
<br />
A few months ago, I wrote<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html an article on digital audio and why 24bit/192kHz music downloads don't make sense].<br />
In the article, I<br />
mentioned--almost in passing--that a digital waveform is<br />
[http://people.xiph.org/~xiphmont/demo/neil-young.html#toc_sfam not a stairstep],<br />
and you certainly don't get a stairstep when you<br />
[[WikiPedia:Digital-to-analog_converter|convert from digital back to analog]].<br />
<br />
Of everything in the entire article, '''that''' was the number one thing<br />
people wrote about. In fact, more than half the mail I got was questions and<br />
comments about basic digital signal behavior. Since there's interest, let's<br />
take a little time to play with some ''simple'' digital signals.<br />
<br />
==Veritas ex machina==<br />
[[Image:Dsat_002.jpg|200px|right]]<br />
[[Image:Dsat_003.jpg|200px|right]]<br />
[[Image:Dsat_004.jpg|200px|right]]<br />
[[Image:Dsat_005.jpg|200px|right]]<br />
<br />
Pretend for a moment that we have no idea how digital signals really<br />
behave. In that case it doesn't make sense for us to use digital test<br />
equipment either. Fortunately for this exercise, there's still plenty<br />
of working analog lab equipment out there.<br />
<br />
First up, we need a [[WikiPedia:Function_generator|signal generator]] to provide us with analog input<br />
signals--in this case, an<br />
[http://www.home.agilent.com/en/pd-3325A%3Aepsg%3Apro-pn-3325A/synthesizer-function-generator?pm=PL&nid=-536900197.536896863&cc=SE&lc=swe HP3325]<br />
from 1978. It's still a pretty good<br />
generator, so if you don't mind the size, the weight, the power<br />
consumption, and the noisy fan, you can find them on eBay... occasionally<br />
for only slightly more than you'll pay for shipping.<br />
<br />
Next, we'll observe our analog waveforms on [[WikiPedia:Oscilloscope_types#Cathode-ray_oscilloscope_.28CRO.29|analog oscilloscopes]],<br />
like this Tektronix 2246 from the mid-90s, one of the last and very best analog scopes ever made. Every home lab should have one.<br />
<br />
...and finally inspect the [[WikiPedia:Spectral_density#Electrical_engineering|frequency spectrum]] of our signals using an<br />
[[WikiPedia:Spectrum_analyzer#Swept-tuned|analog spectrum analyzer]], this<br />
[http://www.home.agilent.com/en/pd-3585A%3Aepsg%3Apro-pn-3585A/spectrum-analyzer-high-perf-20hz-40mhz?pm=PL&nid=-536900197.536897319&cc=SE&lc=swe HP3585]<br />
from the same product line as<br />
the signal generator. Like the other equipment here it has<br />
[http://www.hp9845.net/9845/hardware/processors/ a rudimentary and hilariously large microcontroller],<br />
but the signal path<br />
from input to what you see on the screen is completely analog.<br />
<br />
All of this equipment is vintage, but aside from its raw tonnage, the specs are still quite good.<br />
<br />
At the moment, we have our signal generator set to output a nice 1 [[WikiPedia:Hertz#SI_multiples|kHz]]<br />
sine wave at one [[WikiPedia:Volt|Volt]] [[WikiPedia:Amplitude#Root_mean_square_amplitude|RMS]].<br />
We see the sine wave on the oscilloscope, can verify that it is indeed<br />
1 kHz at 1 Volt RMS, which is 2.8 Volts<br />
[[WikiPedia:Amplitude#Peak-to-peak_amplitude|peak-to-peak]],<br />
and that matches the<br />
measurement on the spectrum analyzer as well.<br />
<br />
The analyzer also shows some low-level [[WikiPedia:White_noise|white noise]]<br />
and just a bit of [[WikiPedia:Harmonic_distortion#Harmonic_distortion|harmonic distortion]],<br />
with the highest peak about 70[[WikiPedia:Decibel|dB]] or so below<br />
[[WikiPedia:Fundamental_frequency|the fundamental]].<br />
Now, this doesn't matter at all in our demos, but I<br />
wanted to point it out now just in case you didn't notice it until<br />
later.<br />
<br />
Now, we drop digital sampling in the middle.<br />
<br />
For the conversion, we'll use a boring, consumer-grade, eMagic USB1<br />
audio device. It's also more than ten years old at this point, and it's<br />
getting obsolete.<br />
<br />
A recent converter can easily have an order of magnitude better specs.<br />
[[WikiPedia:Reconstruction_filter#Sampled_data_reconstruction_filters|Flatness]],<br />
[[WikiPedia:Analog-to-digital_converter#Non-linearity|linearity]],<br />
[[WikiPedia:Jitter#Sampling_jitter|jitter]],<br />
[[WikiPedia:Noise_floor|noise behavior]],<br />
[[WikiPedia:Digital-to-analog_converter#DAC_performance|everything]]...<br />
you may not<br />
have noticed. Just because we can measure an improvement doesn't<br />
mean we can hear it, and even these old consumer boxes were already at<br />
the edge of ideal transparency.<br />
<br />
The eMagic connects to my ThinkPad, which displays a digital<br />
waveform and spectrum for comparison, then the ThinkPad<br />
sends the digital signal right back out to the eMagic for<br />
re-conversion to analog and observation on the output scopes.<br />
<br />
Input to output, left to right.<br />
<br style="clear:both;"/><br />
<br />
==Stairsteps==<br />
[[Image:Dsat 006.jpg|360px|right]]<br />
[[Image:Dsat 007.png|360px|right]]<br />
OK, it's go time. We begin by converting an analog signal to digital and<br />
then right back to analog again with no other steps.<br />
<br />
The signal generator is set to produce a 1kHz sine wave just like<br />
before.<br />
<br />
We can see our analog sine wave on our input-side oscilloscope.<br />
<br />
We digitize our signal to<br />
[[Videos/A_Digital_Media_Primer_For_Geeks#Raw_.28digital_audio.29_meat|16 bit PCM at 44.1kHz]],<br />
same as on a CD.<br />
The spectrum of the digitized signal matches what we saw earlier<br />
<br />
and what we see now on the analog spectrum analyzer, aside from its <br />
[[WikiPedia:High_impedance|high-impedance input]] being just a smidge noisier.<br />
<br />
For now, the waveform display shows our digitized sine wave as a<br />
stairstep pattern, one step for each sample.<br />
<br />
And when we look at the output signal that's been converted<br />
from digital back to analog, we see...<br />
<br />
It's exactly like the original sine wave. No stairsteps.<br />
<br />
OK, 1 kHz is still a fairly low frequency, maybe the stairsteps are just<br />
hard to see or they're being smoothed away. Fair enough. Let's choose<br />
a higher frequency, something close to [[WikiPedia:Nyquist_frequency|Nyquist]], say 15kHz.<br />
<br />
Now the sine wave is represented by less than three samples per cycle, and...<br />
<br />
the digital waveform looks pretty awful. Well, looks<br />
can be deceiving. The analog output...<br />
<br />
is still a perfect sine wave, exactly like the original.<br />
<br />
Let's keep going up.<br />
<br />
Let's see if I can do this without blocking any cameras.<br />
<br />
16kHz.... 17kHz... 18kHz... 19kHz... <br />
<br />
20kHz. Welcome to the upper limits of human hearing. The output<br />
waveform is still perfect. No jagged edges, no dropoff, no stairsteps.<br />
<br />
So where'd the stairsteps go? Don't answer, it's a trick question.<br />
They were never there.<br />
<br />
Drawing a digital waveform as a stairstep... was wrong to begin with.<br />
<br />
Why? A stairstep is a continuous-time function. It's jagged, and it's<br />
piecewise, but it has a defined value at every point in time.<br />
<br />
A sampled signal is entirely different. It's discrete-time; it's only<br />
got a value right at each instantaneous sample point and it's<br />
undefined, there is no value at all, everywhere between. A<br />
discrete-time signal is properly drawn as a lollipop graph.<br />
<br />
The continuous, analog counterpart of a digital signal passes<br />
smoothly through each sample point, and that's just as true for high<br />
frequencies as it is for low.<br />
<br />
Now, the interesting and not at all obvious bit is: [[WikiPedia:Nyquist%E2%80%93Shannon_sampling_theorem|there's only one<br />
bandlimited signal that passes exactly through each sample point]]. It's<br />
a unique solution. So if you sample a bandlimited signal and then<br />
convert it back, the original input is also the only possible output.<br />
<br />
[[Image:Dsat 008.png|360px|right]]<br />
<br />
And before you say, "oh, I can draw a different signal that passes<br />
through those points", well, yes you can, but if it differs even<br />
minutely from the original, it includes frequency content at or beyond<br />
Nyquist, breaks the bandlimiting requirement and isn't a valid<br />
solution.<br />
<br />
So how did everyone get confused and start thinking of digital signals<br />
as stairsteps? I can think of two good reasons.<br />
<br />
First: it's easy enough to convert a sampled signal to a true stairstep. Just<br />
extend each sample value forward until the next sample period. This is<br />
called a [[WikiPedia:Zero-order hold|zero-order hold]], and it's an important part of how some<br />
digital-to-analog converters work, especially the simplest ones.<br />
<br />
So, anyone who looks up [[WikiPedia:Digital-to-analog_converter#Practical_operation|digital-to-analog converter or<br />
digital-to-analog conversion]] is probably going to see a diagram of a<br />
stairstep waveform somewhere, but that's not a finished conversion,<br />
and it's not the signal that comes out.<br />
<br />
Second, and this is probably the more likely reason, engineers who<br />
supposedly know better, like me, draw stairsteps even though they're<br />
technically wrong. It's a sort of like a one-dimensional version of<br />
[[WikiPedia:MacPaint#Development|fat bits in an image editor]].<br />
<br />
Pixels aren't squares either, they're samples of a 2-dimensional<br />
function space and so they're also, conceptually, infinitely small<br />
points. Practically, it's a real pain in the ass to see or manipulate<br />
infinitely small anything, so big squares it is. Digital stairstep<br />
drawings are exactly the same thing.<br />
<br />
It's just a convenient drawing. The stairsteps aren't really there.<br />
<br />
==Bit-depth==<br />
[[Image:Dsat_009.jpg|360px|right]]<br />
[[Image:Dsat_010.jpg|260px|right]]<br />
<br />
When we convert a digital signal back to analog, the result is<br />
''also'' smooth regardless of the [[WikiPedia:Audio_bit_depth|bit depth]]. 24 bits or 16 bits...<br />
or 8 bits... it doesn't matter.<br />
<br />
So does that mean that the digital bit depth makes no difference at<br />
all? Of course not.<br />
<br />
Channel 2 here is the same sine wave input, but we quantize with<br />
[[WikiPedia:Dither|dither]] down to 8 bits.<br />
<br />
On the scope, we still see a nice<br />
smooth sine wave on channel 2. Look very close, and you'll also see a<br />
bit more noise. That's a clue.<br />
<br />
If we look at the spectrum of the signal... aha! Our sine wave is<br />
still there unaffected, but the noise level of the 8-bit signal on<br />
the second channel is much higher!<br />
<br />
And that's the difference the number of bits makes. That's it!<br />
<br />
When we digitize a signal, first we sample it. The<br />
sampling step is perfect; it loses nothing. But then we [[WikiPedia:Quantization_(sound_processing)|quantize]] it,<br />
and [[WikiPedia:Quantization_error|quantization adds noise]].<br />
<br />
The number of bits determines how much noise and so the level of the<br />
noise floor.<br />
<br />
What does this dithered quantization noise sound like? Let's listen<br />
to our 8-bit sine wave.<br />
<br />
That may have been hard to hear anything but the tone. Let's listen<br />
to just the noise after we notch out the sine wave and then bring the<br />
gain up a bit because the noise is quiet.<br />
<br />
Those of you who have used analog recording equipment may have just<br />
thought to yourselves, "My goodness! That sounds like tape hiss!"<br />
Well, it doesn't just sound like tape hiss, it acts like it too, and<br />
if we use a [[WikiPedia:Dither#Different_types|gaussian dither]] then it's<br />
[[WikiPedia:Central_limit_theorem|mathematically equivalent]] in every way. It ''is'' tape hiss.<br />
<br />
Intuitively, that means that we can measure tape hiss and thus the noise floor<br />
of [[WikiPedia:Magnetic_tape_sound_recording|magnetic audio tape]]<br />
in [[WikiPedia:Shannon–Hartley_theorem#Examples|bits instead of decibels]], in order to put things in a<br />
digital perspective. [[WikiPedia:Compact cassettes|Compact cassettes]] (for those of you who are old enough to remember them) could reach as<br />
deep as 9 bits in perfect conditions, though 5 to 6 bits was<br />
more typical, especially if it was a recording made on a<br />
[[WikiPedia:Cassette_deck|tape deck]]. That's right... your mix tapes were only about 6 bits<br />
deep... if you were lucky!<br />
<br />
The very best professional [[WikiPedia:Reel-to-reel_audio_tape_recording|open reel tape]] used in studios could barely<br />
hit... any guesses? 13 bits ''with'' [[WikiPedia:Reel-to-reel_audio_tape_recording#Noise_reduction|advanced noise reduction]]. And<br />
that's why seeing '[[WikiPedia:SPARS_code|D D D]]' on a [[WikiPedia:Compact_disk|Compact Disc]] used to be such a big,<br />
high-end deal.<br />
<br />
==Dither==<br />
[[Image:Dsat_011.png|360px|right]]<br />
<br />
I keep saying that I'm quantizing with [[Wikipedia:dither|dither]], so what is dither<br />
exactly and, more importantly, what does it do?<br />
<br />
The simple way to quantize a signal is to choose the digital<br />
amplitude value closest to the original analog amplitude. [[WikiPedia:Rounding|Obvious]],<br />
right? Unfortunately, the exact noise you get from this simple<br />
quantization scheme depends somewhat on the input signal,<br />
<br />
so we may get noise that's inconsistent, or causes distortion, or is<br />
undesirable in some other way.<br />
<br style="clear:both;"/><br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
'''Going deeper…'''<br />
*Cameron Nicklaus Christou's thesis [http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf Optimal Dither and Noise Shaping in Image Processing] provides an ''excellent'' explanation of dither and noise shaping.<br />
</div></center><br />
<br />
Dither is specially-constructed noise that substitutes for the noise<br />
produced by simple quantization. Dither doesn't [[WikiPedia:Sound_masking|drown out or mask]]<br />
quantization noise, it actually replaces it with noise characteristics<br />
of our choosing that aren't influenced by the input.<br />
<br />
Let's ''watch'' what dither does. The signal generator has too much noise for this test so we'll produce a mathematically perfect sine wave with the ThinkPad and quantize it to 8 bits with dithering.<br />
<br />
We see a nice sine wave on the waveform display and output scope and, once the analog spectrum analyzer catches up...<br />
a clean frequency peak with a uniform noise floor on both spectral displays<br />
just like before. Again, this is with dither.<br />
<br />
Now I turn dithering off.<br />
<br />
The quantization noise, that dither had spread out into a nice, flat noise<br />
floor, piles up into harmonic distortion peaks. The noise floor is<br />
lower, but the level of distortion becomes nonzero, and the distortion<br />
peaks sit higher than the dithering noise did.<br />
<br />
At 8 bits this effect is exaggerated. At 16 bits,<br />
even without dither, harmonic distortion is going to be so low as to<br />
be completely inaudible.<br />
<br />
Still, we can use dither to eliminate it completely if we so choose.<br />
<br />
Turning the dither off again for a moment, you'll notice that the<br />
absolute level of distortion from undithered quantization stays<br />
approximately constant regardless of the input amplitude.<br />
But when the signal level drops below a half a bit, everything<br />
quantizes to zero.<br />
<br />
In a sense, everything quantizing to zero is just 100% distortion!<br />
Dither eliminates this distortion too. We reenable dither<br />
and ... there's our signal back at 1/4 bit, with our nice flat noise floor.<br />
<br />
The noise floor doesn't have to be flat. Dither is noise of our<br />
choosing, so let's choose a noise as [http://www.acoustics.salford.ac.uk/res/cox/sound_quality/?content=subjective inoffensive] and<br />
[[WikiPedia:Absolute_threshold_of_hearing|difficult to notice]]<br />
as possible.<br />
<br />
Our hearing is most sensitive in the midrange from 2kHz to 4kHz,<br />
so that's where background noise is going to be the most obvious.<br />
We can [[WikiPedia:Noise_shaping|shape dithering noise]] away from sensitive frequencies to where<br />
hearing is less sensitive, usually the highest frequencies.<br />
<br />
16-bit dithering noise is normally much too quiet to hear at all, but<br />
let's listen to our noise shaping example, again with the gain<br />
brought way up...<br />
<br />
Lastly, dithered quantization noise ''is'' higher [[WikiPedia:power|Sound_power]] overall<br />
than undithered quantization noise even when it sounds quieter, and<br />
you can see that on a [[WikiPedia:VU_meter|VU meter]] during passages of near-silence. But<br />
dither isn't only an on or off choice. We can reduce the dither's<br />
power to balance less noise against a bit of distortion to minimize<br />
the overall effect.<br />
<br />
We'll also [[WikiPedia:Amplitude_modulation|modulate the input signal]] like this to show how a varying input affects the quantization noise. At<br />
full dithering power, the noise is uniform, constant, and featureless<br />
just like we expect:<br />
<br />
As we reduce the dither's power, the input increasingly<br />
affects the amplitude and the character of the quantization noise.<br />
Shaped dither behaves similarly, but noise shaping lends one more nice<br />
advantage. To make a long story short, it can use a somewhat lower<br />
dither power before the input has as much effect on the output.<br />
<br />
Despite all the time I just spent on dither, we're talking about<br />
differences that start 100 decibels and more below [[WikiPedia:Full_scale|full scale]]. Maybe<br />
if the CD had been<br />
[http://www.research.philips.com/technologies/projects/cd/index.html 14 bits as originally designed],<br />
dither ''might'' be<br />
more important. Maybe. At 16 bits, really, it's mostly a wash. You<br />
can think of dither as an insurance policy that gives several extra<br />
decibels of dynamic range just in case. The simple fact is, though, no<br />
one ever ruined a great recording by not dithering the final master.<br />
<br />
==Bandlimitation and timing==<br />
[[image:Dsat_013.jpg|360px|right]]<br />
<br />
We've been using [[WikiPedia:Sine_wave|sine waves]]. They're the obvious choice when what we<br />
want to see is a system's behavior at a given isolated frequency. Now<br />
let's look at something a bit more complex. What should we expect to<br />
happen when I change the input to a [[WikiPedia:Square_wave|square wave]]...<br />
<br />
The input scope confirms our 1kHz square wave. The output scope shows..<br />
<br />
<br />
Exactly what it should.<br />
...<br />
What is a square wave really? <br />
<br />
<br />
Well, we can say it's a waveform that's some positive value for half a cycle and then transitions instantaneously to a negative value for the other half.<br />
<br />
:<math><br />
\ x(t) = \begin{cases} 1, & |t| < T_1 \\ 0, & T_1 < |t| \leq {1 \over 2}T \end{cases}<br />
</math><br />
<br />
But that doesn't really tell us anything useful about how that input becomes this output.<br />
<br />
Then we remember that any waveform is also [[WikiPedia:Fourier_series|the sum of discrete frequencies]],<br />
and a square wave is particularly simple sum: a fundamental and an<br />
infinite series of [[WikiPedia:Even_and_odd_functions#Harmonics|odd harmonics]]. Sum them all up, you get a<br />
square wave.<br />
<br />
[[Image:dsat_015.jpg|360px|right]]<br />
:<math>\begin{align}<br />
x_{\mathrm{square}}(t) = \frac{4}{\pi}\sin(\omega t) + \frac{4}{3\pi}\sin(3\omega t) + \frac{4}{5\pi}\sin(5\omega t) + \\<br />
\frac{4}{7\pi}\sin(7\omega t) + \frac{4}{9\pi}\sin(9\omega t) + \frac{4}{11\pi}\sin(11\omega t) + \\ <br />
\frac{4}{13\pi}\sin(13\omega t) + \frac{4}{15\pi}\sin(15\omega t) + \frac{4}{17\pi}\sin(17\omega t) + \\<br />
\frac{4}{19\pi}\sin(19\omega t) + \frac{4}{21\pi}\sin(21\omega t) + \frac{4}{23\pi}\sin(23\omega t) + \\<br />
\frac{4}{25\pi}\sin(25\omega t) + \frac{4}{27\pi}\sin(27\omega t) + \frac{4}{29\pi}\sin(29\omega t) + \\<br />
\frac{4}{31\pi}\sin(31\omega t) + \frac{4}{33\pi}\sin(33\omega t) + \cdots <br />
\end{align}</math><br />
<br />
At first glance, that doesn't seem very useful either. You have to sum up an infinite number of harmonics to get the answer. ''Ah'', but we don't have an infinite number of harmonics.<br />
<br />
We're using a quite sharp [[WikiPedia:Low-pass_filter|anti-aliasing filter]] that cuts off right<br />
above 20kHz, so our signal is [[WikiPedia:Bandlimiting|bandlimited]], so only the first ten terms make it through.<br />
<br />
..and that's exactly what we see on the output scope.<br />
<br />
The rippling you see around sharp edges in a bandlimited signal is called the [[WikiPedia:/Gibbs_phenomenon|Gibbs effect]]. It happens whenever you slice off part of the frequency domain in the middle of nonzero energy.<br />
<br />
The usual rule of thumb you'll hear is "the sharper the cutoff, the<br />
stronger the rippling", which is approximately true, but we have to be<br />
careful how we think about it.<br />
For example... what would you expect our quite sharp anti-aliasing filter<br />
to do if I run our signal through it a second time?<br />
<br />
Aside from adding a few fractional cycles of delay, the answer is...<br />
nothing at all. The signal is already bandlimited. Bandlimiting it<br />
again doesn't do anything. A second pass can't remove frequencies<br />
that we already removed.<br />
<br />
And that's important. People tend to think of the ripples as<br />
a kind of [[WikiPedia:Sonic_artifact|artifact]] that's added by anti-aliasing and [[WikiPedia:Reconstruction_filter|anti-imaging]]<br />
filters, implying that the ripples get worse each time the signal<br />
passes through. We can see that in this case that didn't happen. So<br />
was it really the filter that added the ripples the first time<br />
through? No, not really. It's a subtle distinction, but Gibbs effect<br />
ripples aren't added by filters, they're just part of what a<br />
bandlimited signal ''is''.<br />
<br />
Even if we synthetically construct what looks like a perfect digital<br />
square wave,<br />
<br />
it's still limited to the channel bandwidth. Remember,<br />
the stairstep representation is misleading.<br />
<br />
What we really have here are instantaneous sample points,<br />
<br />
and only one bandlimited signal fits those points. All we did when we<br />
drew our apparently perfect square wave was line up the sample points<br />
just right so it appeared that there were no ripples if we played<br />
[[WikiPedia:Interpolation|connect-the-dots]].<br />
<br />
But the original bandlimited signal, complete with ripples, was<br />
still there.<br />
<br />
[[image:Dsat_014.gif|360px|right]]<br />
And that leads us to one more important point. You've probably heard<br />
that the timing precision of a digital signal is limited by its sample<br />
rate; put another way,<br />
<br />
that digital signals can't represent anything that falls between the<br />
samples.. implying that [[WikiPedia:Dirac_delta_function|impulses]] or<br />
[[WikiPedia:Synthesizer#ADSR_envelope|fast attacks]] have to align exactly<br />
with a sample, or the timing gets mangled... or they just disappear.<br />
<br />
At this point, we can easily see why that's wrong.<br />
<br />
Again, our input signals are bandlimited. And digital signals are<br />
samples, not stairsteps, not 'connect-the-dots'. We most certainly<br />
can, for example, put the rising edge of our bandlimited square wave<br />
anywhere we want between samples.<br />
<br />
It's represented perfectly and it's reconstructed perfectly.<br />
<br />
==Epilogue==<br />
<br />
[[Image:Moffey.jpg|360px|right]]<br />
<br />
Just like in [[Videos/A_Digital_Media_Primer_For_Geeks|the previous episode]], we've covered a broad range of<br />
topics, and yet barely scratched the surface of each one. If anything, my<br />
sins of omission are greater this time around... but this is a good<br />
stopping point.<br />
<br />
Or maybe, a good starting point. Dig deeper. Experiment. I chose my<br />
demos very carefully to be simple and give clear results. You can<br />
reproduce every one of them on your own if you like. But let's face<br />
it, sometimes we learn the most about a spiffy toy by breaking it open<br />
and studying all the pieces that fall out. And that's OK, we're<br />
engineers. Play with the demo parameters, hack up the code, set up<br />
alternate experiments. The source code for everything, including the<br />
little pushbutton demo application, is up at xiph.org.<br />
<br />
In the course of experimentation, you're likely to run into something<br />
that you didn't expect and can't explain. Don't worry! My earlier<br />
snark aside, Wikipedia is fantastic for exactly this kind of casual<br />
research. And, if you're really serious about understanding signals,<br />
several universities have advanced materials online, such as the<br />
[http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-003-signals-and-systems-spring-2010/index.htm 6.003]<br />
and<br />
[http://ocw.mit.edu/resources/res-6-007-signals-and-systems-spring-2011/ RES.6-007]<br />
Signals and Systems modules at MIT OpenCourseWare. And of<br />
course, there's always the [http://webchat.freenode.net/?channels=xiph community here at Xiph.Org].<br />
<br />
Digging deeper or not, I am out of coffee, so, until next time, happy<br />
hacking!<br />
<br />
==Credits==<br />
[[Image:Dmpfg_019.png|360px|right]]<br />
Written by: Christopher (Monty) Montgomery and the Xiph.Org Community<br />
<br />
Special thanks to:<br />
*Heidi Baumgartner, for the second Tektronix oscilloscope<br />
*Gregory Maxwell and Dr. Timothy Terriberry, for additional technical review<br />
<br />
Intro, title and credits music:<br><br />
"Andy Warhol Is Gone", by Lousy Robot<br><br />
Used by permission of Lousy Robot.<br><br />
Original source track All Rights Reserved.<br><br />
[http://www.lousyrobot.com www.lousyrobot.com]<br />
<br />
This Video Was Produced Entirely With Free and Open Source Software:<br><br />
<br />
*[http://www.gnu.org/ GNU]<br><br />
*[http://www.linux.org/ Linux]<br><br />
*[http://fedoraproject.org/ Fedora]<br><br />
*[http://cinelerra.org/ Cinelerra]<br><br />
*[http://www.gimp.org/ The Gimp]<br><br />
*[http://audacity.sourceforge.net/ Audacity]<br><br />
*[http://svn.xiph.org/trunk/postfish/README Postfish]<br><br />
*[http://gstreamer.freedesktop.org/ Gstreamer]<br><br />
<br />
All trademarks are the property of their respective owners. <br />
<br />
*''Complete video'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
*''Text transcript and Wiki edition'' [http://creativecommons.org/licenses/by-sa/3.0/legalcode CC-BY-SA]<br><br />
<br />
A Co-Production of Xiph.Org and Red Hat, Inc.<br><br />
(C) 2012-2013, Some Rights Reserved<br><br />
<br />
== Use The Source Luke ==<br />
<br />
As stated in the Epilogue, everything that appears in the video demos is driven by open source software, which means the source is both available for inspection and freely usable by the community. The Thinkpad that appears in the video was running Fedora 17 and Gnome Shell (Gnome 3). The demonstration software does not require Fedora specifically, but it does require Gnu/Linux to run in its current form. In all, the video involved just under 50,000 lines of new and custom-purpose code (including contributions to non-Xiph projects such as Cinelerra and Gromit).<br />
<br />
=== The Spectrum and Waveform Viewer ===<br />
<br />
The realtime software spectrum analyzer application that appears in the video was a preexisting application that was dusted off and updated for use in the video. The waveform viewer (effectively a simple software oscilloscope) was written from scratch making use of some of the internals from the spectrum analyzer application. Both are available from Xiph.Org svn:<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Spectrum and Waveform applications is found at:<br />
https://svn.xiph.org/trunk/spectrum/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/spectrum<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/trunk/spectrum<br />
</div></center><br />
<br />
Spectrum and Waveform both expect an input stream on the command line, either as raw data or as a WAV file.<br />
<br />
=== GTK-Bounce ===<br />
<br />
The touch-controlled application used in the video is named 'gtk-bounce' and was custom-written for the sole purpose of the in-video demonstrations. It is so named because, for the most part, all it does is read the input from an audio device, and then immediately write the same data back out for playback. It also forwards a copy of this data to up to two external monitoring applications, and in several demos, applies simple filters or generates simple waveforms. It includes several demos not included in the video.<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for gtk-bounce is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/bounce/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/bounce/<br />
</div></center><br />
<br />
The application is somewhat hardwired for specific demo parameters, but most of the hardwired settings can be found at the top of each source file. As found in SVN, the application expects an ALSA hardware audio device at hw:1, and if none if found, it will wait for one to appear. Once a sound device is successfully initialized, it expects to find and open two pipes named pipe0 and pipe1 for output in the current directory. In the video, the waveform and spectrum applications are started to take input from pipe0 and pipe1 respectively. The output sent to the two pipes is identical, and in most demos matches the output data sent to the hardware device for conversion to analog. The only exception is the tenth demo panel (which does not appear in the video) where gtk-bounce can be set to monitor the hardware inputs instead while the outputs are used to produce test waveforms.<br />
<br />
Assuming gtk-bounce, spectrum and waveform have been checked out and built, the configuration seen in the video can be started using the following commands:<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
* make the pipe fifos for the applications to communicate (only needs to be done once)<br />
mkfifo pipe0 pipe1<br />
* start all three applications<br />
waveform pipe0 & spectrum pipe1 & gtk-bounce &<br />
</div></center><br />
<br />
Gtk-bounce consists of eleven pushbutton panels (numbered zero through ten) that can be selected by scrolling up and dwon with the arrow buttons on the right side. Each panel is intended for a specific demo or part of a demo.<br />
<br />
[[Image:Dsat-panel0.png|right]]<br />
* '''Panel 0''': This panel presents buttons that allow the sound card to be configured in several sampling rates and bit depths. Samples read from the audio inputs are sent to the output pipes and audio outputs for playback without modification.<br />
<div style="clear: both"></div><br />
<br />
* Panel 1: <br />
<br />
* Panel 2: <br />
<br />
* Panel 3: <br />
<br />
* Panel 4: <br />
<br />
* Panel 5: <br />
<br />
* Panel 6: <br />
<br />
* Panel 7: <br />
<br />
* Panel 8: <br />
<br />
* Panel 9: <br />
<br />
* Panel 10:<br />
<br />
=== Cairo Animations ===<br />
<br />
The animations featured throughout the Episode 2 video were rapid-development spaghetti hack-jobs coded by hand in raw Cairo. Each module generated a series of PNG stills that were then stitched into an animation with Cinelerra or mplayer. In the interest of pointing and laughing at what really bad code looks like...<br />
<br />
<center><div style="background-color:#DDDDFF;border-color:#CCCCDD;border-style:solid;width:80%;padding:0 1em 1em 1em;text-align:left;"><br />
*Source for the Cairo animations is found at:<br />
https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*The source can be checked out of svn using the following command line:<br />
svn co https://svn.xiph.org/trunk/Xiph-episode-II/cairo/<br />
*Trac is a convenient way to browse the source without checking out a copy:<br />
https://trac.xiph.org/browser/Xiph-episode-II/cairo/<br />
</div></center></div>Xiphmont