Focusrite Scarlett 6i6 and Pulseaudio

Oh, pulseaudio, how do I love thee...

The Focusrite Scarlett 6i6 is a 2 Mic, 2 Line, 2 Digital input, 4 Line, 2 Digital output audio interface and is presented to the Linux machine as a 12 output, 6 input USB2.0 class compliant soundcard. Strange, but that's what it is. Now, pulseaudio, not very smart in the first place, gets confused and only ever wants to use this card as a "multichannel" output, with outputs 1/2 deprived of bass, and output 6 (typically mapped to the s/pdif output) being a subwoofer. Not useful when listening over headphones.

After looking through the non-existing pulseaudio-documentation regarding udev, and searching on the web, I've came up with a workaround. This is at least useful to use the card as a normal stereo output.

To get output on the 2nd headphone output, use alsamixer to map Master 2L and Master 2R source to PCM1 and PCM2. The same applies to the S/PDIF output (Master 3L/R).

Bug filed.

➜  ~  cat /usr/share/pulseaudio/alsa-mixer/profile-sets/focusrite-scarlett-6i6.conf 
; Based on native-instruments-traktor-audio10.conf

;
; Focusrite Scarlett 6i6 has 6 physical inputs/outputs
; Inputs
;  2x  Microphone/Line on front
;  2x  Line on back
;  2x  S/PDIF coaxial on back
; Outputs
;  2x  Headphone (Out1/2, Out 3/4) on front
;  2x  Line on back (Out 1..4)
;  2x  S/PDIF coaxial on back
;
; It's presented as a 6 input, 12 output interface to the PC, so
; we have to create some mappings. Actual routing is configurable
; in ALSA mixer. I prefer a 1:1 mapping to physical outputs.
;

[General]
auto-profiles = no

[Mapping analog-out]
description = Analog Outputs
device-strings = hw:%f
channel-map = left,right,aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7,aux8,aux9

[Mapping analog-in]
description = Analog Inputs
device-strings = hw:%f
channel-map = left,right,aux0,aux1,aux2,aux3
direction = input


[Profile output:analog-out+input:analog-in]
description = Analog Duplex
output-mappings = analog-out
input-mappings = analog-in
priority = 100
skip-probe = yes

➜  ~  cat /etc/udev/rules.d/99-pulseaudio-local.rules 

SUBSYSTEM!="sound", GOTO="pulseaudio_local_end"

ACTION!="change", GOTO="pulseaudio_local_end"

KERNEL!="card*", GOTO="pulseaudio_local_end"

SUBSYSTEMS=="usb", GOTO="pulseaudio_local_check_usb"

LABEL="pulseaudio_local_check_usb"

##

# The Focusrite Scarlett 6i6 only runs as 12 playback and 6 capture channels!

# (mappable using the internal mixer)

# Bus 002 Device 004: ID 1235:8012 Focusrite-Novation Scarlett 6i6

##

ATTRS{idVendor}=="1235", ATTRS{idProduct}=="8012", ENV{PULSE_PROFILE_SET}="focusrite-scarlett-6i6.conf"

LABEL="pulseaudio_local_end"

Behringer "X-Air" XR18 Teardown

Here's a teardown of a Behringer XR18 (sometimes spelled X18R) Compact Digital Mixer. There's a full album with all pictures I took.

To open the device, you have to remove the rubber bumpers on the sides (which can be replaced with rack-ears). Two of the tiny screws on each side don't have to be removed, this lets the bottom shell of the case keep more mechanical strength. Then two halves slide open, an L-shaped top-plus-front-side part, and the rest enclosing sides, bottom and back side.

From Behringer XR18 Teardown

In the inside, you can find the power supply, a digital board (+ analog outputs) and a stack of three boards mainly responsible for the analog mic/line inputs. The topmost board (which I didn't remove because it's attached to the case by all the XLR connectors) mainly has connectors and the headphone amp. The middle board carries circuitry for the actual mic preamp. The bottom board has a few opamps and the ADCs for the analog inputs.

From Behringer XR18 Teardown

Power Supply

Generally the manufacturing is pretty nice and everything looks produced to tight tolerances. I could see no gaps, nothing loose. The only downside I see is the powersupply and the mains connector: The supply gets very hot during normal operation (and no devices running on phantom power were connected during the few hours it was in operation before opening the case). The mains connector is isolated with an additional layer of sticky tape, and fastened with hot glue. This looks rather sloppy.

From Behringer XR18 Teardown

Interestingly Behringer (the Music Group) designed their own supply!

From Behringer XR18 Teardown

Digital/DSP (+analog output) PCB

People are generally annoyed by the lack of support for WPA/WPA2 with the builtin WiFi access point. It's essentially a Microchip MRF24WG0MB Module

From Behringer XR18 Teardown

The USB audio interface seems to be powered by a XMOS 16L7C10 1000 MIPS, 128 kB SRAM, 32-bit multicore microcontroller and its associated Microchip USB3340 Enhanced Single Supply Hi-Speed USB ULPI Transceiver.

From Behringer XR18 Teardown

The actual user-facing functionality obviously is orchestrated by a Freescale MCIMX253DJM4A i.MX25 400 MHz, single core, ARM 926EJ-S, the network is connected with a standard Microchip LAN8720A Small Footprint RMII 10/100 Ethernet Transceiver.

From Behringer XR18 Teardown

From Behringer XR18 Teardown

The eight XLR analog outputs are fed by a CS4385 Cirrus Logic octal 24 bit DAC, the CS4272 Cirrus Logic 24 bit stereo audio codec feeds the headphone output and digitizes the line input (ch 17/18). [it's the only ADC/DAC left after accounting for the 8 analog outputs and 16 analog inputs and corresponding octal converters].

From Behringer XR18 Teardown

Routing of signals probably is taken care of by the logic inside this Xilinx XC6SLX4 (Spartan 6) FPGA. It's the smallest of the Spartan 6 family -- and while it has 216 kBit of blockram and 8 "DSP Slices" which feature multipliers, adders and accumulators, I doubt that it does any computational work. Maybe it scales the output level or so, though...

From Behringer XR18 Teardown

There's a truckload of New Japan Radio Corporation NJM4580 Dual Opamps used inside the XR18, and
a bunch of them seem to take care of driving the differential XLR analog outputs.

From Behringer XR18 Teardown

Mic/Line ADC

The most interesting chip on the ADC board (bottom-most in the three-board stack) is the Cirrus Logic CS5368 octal 24bit ADC. There are two of them, for 16 inputs in total. There are also a bunch of NJM4580 (1+1/2 for each channel), likely for a final level adjust and to drive the differential inputs of the ADCs.

From Behringer XR18 Teardown

Mic Preamp

The board with the mic preamps is rather interesting. The layout seems to be a conventional frontend using discrete transistors as first stage amplification and a NJM4580 as a differential amplifier. There are two Coolaudio V411 analog switches per channel to adjust the gain, and quite a few shift registers to provide the control inputs to the analog switches.

From Behringer XR18 Teardown

From Behringer XR18 Teardown

From Behringer XR18 Teardown

From Behringer XR18 Teardown

Connector PCB

The connector PCB is very uninteresting. One very thoughtful detail, though, is that they drilled holes beneath the XLR/TRS combo jacks. If you ever had to desolder one of those because the TIP of a TRS connector broke off you appreciate this. I did not remove this board, because it's held in place by dozens of screws on the XLR jacks.

From Behringer XR18 Teardown

A OPAMP labeled JRC8074A seems to be the headphone amplifier.

From Behringer XR18 Teardown

Logarithmic Sine Sweep for Impulse Reponse Measurements (in Python/Numpy)

There's quite a lot of software available to do impulse response measurements, e.g. for doing measurements on loudspeakers or electronic audio equipment. Some also use it to sample the impulse responses of rooms and halls to get realistic reverb.

To learn about the technique (on which one can find quite a few publications using google) I'm going to implement the analyses in python/numpy.

The first building block is a small script to generate such a sweep and which I've published, as usual, on github: https://github.com/vogelchr/sweep_analysis

Below you can find a spectrogram made using the magnificent baudline.

From Chris’ Miscellanea

Full Disk Encryption with Cyanogenmod CM12.1 on a Samsung Galaxy S4 Mini

Update August 9th: Just skip to the last line of this post where we realize that we could have spared us all of the hassles and resize2fs from within the running android system ☺.

If you try to enable full disk encryption on Cyanogenmod CM12.1 using the normal settings menu (Security -> Encrypt Phone) it doesn't work, the phone will just soft-reboot and nothing will have happened.

If you "logcat" the debugging log of your phone (using adb logcat) within the huge amount of data, some hint about what might have gone wrong can be found:

➜  ~  grep Cryptfs logcat_encryption.txt 
I/Cryptfs (  199): Check if PFE is activated on Boot
E/Cryptfs (  199): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs (  199): Error getting crypt footer and key
E/Cryptfs (  199): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs (  199): Orig filesystem overlaps crypto footer region.  Cannot encrypt in place.
E/Cryptfs (  199): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs (  199): Orig filesystem overlaps crypto footer region.  Cannot encrypt in place.

On android, the footer that tells the operating system that an partition is encrypted resides on the end of the filesystem and it needs a little space between the logical end of the filesystem in a partition, and the physical end of the partition to be squeezed in when converting a phone from unencrypted to encrypted.

http://forum.xda-developers.com/nexus-4/help/looking-encryption-footer-t2676700

Running the recovery system (boot while keeping Volume-Up and Home pressed), we can have a look at the partition sizes and filesystem details. We learn that on my S4 mini, the userdata partition (mmcblk0p24) has a size of 5685231 1k blocks, and the /data filesystem claims a size of 1421307 4k blocks.

$ adb shell
~ # cat /proc/partitions
major minor  #blocks  name
(...)
 179       24    5685231 mmcblk0p24
~ # tune2fs -l /dev/block/mmcblk0p24 
(...)
Block count:              1421307
(...)
Block size:               4096

As 5685231-1421307*4 = 3, that's only 3 meager 1k blocks at the end of the filesystem, whereas the encryption footer needs a space of at least 16k, the allmighty internet tells me. So, let's build a filesystem that leaves 128kByte of free space on the end as I don't know if Android 5 has enlarged the footer from what the websites I had found claims, or if there's some alignment requirement for it. So I'll be generous. (5685231-128)/4=1421275.75 so I'll create a ext4 filesystem occupying 1421275 4k blocks:

~ # mke2fs -b4096 -T ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata 142127

(note: I made a mistake, ch0pped off the 5!)
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
35600 inodes, 142127 blocks
7106 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=146800640
5 block groups
32768 blocks per group, 32768 fragments per group
7120 inodes per group
Superblock backups stored on blocks: 
32768, 98304

Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Do I really have to mention at this point that this will erase all your files? Alternatively one could try "resizefs" to resize the filesystem, but that program isn't included in my recovery. Anyhow, it seems to be prudent to try encryption on an otherwise virgin install, as one risks data loss anyhow when performing the encryption process and there are reports of phones not booting up correctly after encyption had been enabled.

Then reboot the phone, do a half-hearted initial setup of the device, configure a simple PIN for testing, and encrypt your phone. (I also enabled debugging so that I can run logcat again to catch errors).

$ grep Cryptfs logcat_encryption_newfs.txt
(...)
I/Cryptfs (  196): Check if PFE is activated on Boot
E/Cryptfs (  196): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs (  196): Error getting crypt footer and key
E/Cryptfs (  196): not running with encryption, aborting
E/Cryptfs (  196): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
D/Cryptfs (  196): Just asked init to shut down class main
D/Cryptfs (  196): unmounting /mnt/shell/emulated succeeded
D/Cryptfs (  196): unmounting /data succeeded
I/Cryptfs (  196): keymaster version is 2
I/Cryptfs (  196): Using scrypt for cryptfs KDF
D/Cryptfs (  196): Just triggered post_fs_data
D/Cryptfs (  196): post_fs_data done
D/Cryptfs (  196): Just triggered restart_min_framework
I/Cryptfs (  196): Using scrypt for cryptfs KDF
I/Cryptfs (  196): Enabling support for allow_discards in dmcrypt.
I/Cryptfs (  196): load_crypto_mapping_table: target_type = crypt
I/Cryptfs (  196): load_crypto_mapping_table: real_blk_name = /dev/block/platform/msm_sdcc.1/by-name/userdata, extra_params = 1 allow_discards
I/Cryptfs (  196): Encrypting ext4 filesystem in place...
I/Cryptfs (  196): Encrypting group 0
I/Cryptfs (  196): Encrypting from sector 0
I/Cryptfs (  196): Encrypting group 1
I/Cryptfs (  196): Encrypted to sector 1356288
I/Cryptfs (  196): Encrypting from sector 16777216
I/Cryptfs (  196): Encrypted to sector 16867328
I/Cryptfs (  196): Encrypting from sector 16874496
I/Cryptfs (  196): Encrypted to sector 17014784

The phone will now reboot and ask for the PIN you entered. Unfortunately this takes *ages*! But if everything is fine, you can now setup your phone to your heart's content and set up a real password to have a securely encrypted phone. We'll have to see how stable this encrypted phone will be in daily use.

From Chris’ Miscellanea

Update: I made a mistake and chopped off the "5" at the end, so my filesystem only occupies 1/10 of the available space and has a completely unusable size of 500 MB :-(. So, to not have to start all over again, I'll try to resize the file system in place.

Login to your android device, and check the filesystem size. Indeed /data is completely ridiculous at 500MB.

➜  e2fs  adb shell

shell@serranoltexx:/ $ su

root@serranoltexx:/ # df

Filesystem               Size     Used     Free   Blksize

(...)

/data                  553.0M   490.2M    62.8M   4096

Check the sizes of the underlaying block device, and the dmcrypt mapper:

root@serranoltexx:/ # cat /proc/partitions

major minor  #blocks  name

(...)

 179       24    5685231 mmcblk0p24

(...)

 254        0    5685215 dm-0

Indeed, the crypted partition is exactly 16kB smaller (the crypt footer) than the raw block device. So we can hopefully let resize2fs autodiscover the target size. Unfortunately, we cannot access the block device hosting /data, and we can't umount /data because the android framework is still running. So we use the same method as the volume daemon to shutdown most of android. (your device will not no longer react to user input on the buttons or touch secreen):

root@serranoltexx:/ # setprop vold.decrypt trigger_shutdown_framework

root@serranoltexx:/ # umount /data

root@serranoltexx:/ # e2fsck -f /dev/block/dm-0       

e2fsck 1.42.9 (28-Dec-2013)

Pass 1: Checking inodes, blocks, and sizes

(...)

(fix problems as they appear here)

root@serranoltexx:/ # resize2fs /dev/block/dm-0

resize2fs 1.42.9 (28-Dec-2013)

Resizing the filesystem on /dev/block/dm-0 to 1421303 (4k) blocks.

The filesystem on /dev/block/dm-0 is now 1421303 blocks long.

I rebooted the phone the hard way via sync; echo b >/proc/sysrq-trigger.

Now /data is at the expected size of 5.5 GB.

➜  ~  adb shell df
Filesystem               Size     Used     Free   Blksize
(...)
/data                    5.4G   734.3M     4.7G   4096

Of course, now that we have found out how to resize an ext4 filesystem in place from within android, we realize that we could have made it that way from the beginning 😉. Without data loss. Just run the last 4 commands but using the physical emmc device and append the right number of blocks we need to resize2fs while the device is still unencrypted...

e2fsck /dev/block/mmcblk0p24

resize2fs /dev/block/mmcblk0p24 14221303

That should do the trick. Reboot and run the normal encryption process.

Public Service Announcement: Putty

A recent upgrade of sshd apparently broke my saved putty connections, which have a deprecated key-exchange protocol on the top of the "Algorithm selection policy."

It manifests itself as a long pause, showing a black putty terminal window, followed by the message: PuTTY Fatal Error: Server unexpectedly closed network connection.

The putty event window will show it being stuck in the "Doing Diffie-Hellman group exchange" phase.

From Chris’ Miscellanea

If you run your sshd in debug mode, you'll see that sshd isn't happy with the selection of the key exchange protocol.

➜  ~  sudo /usr/sbin/sshd -p 2222 -d
debug1: sshd version OpenSSH_6.9, OpenSSL 1.0.2c 12 Jun 2015

(...)

debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth]

debug1: expecting SSH2_MSG_KEX_DH_GEX_REQUEST [preauth]

Hm, kex protocol error: type 30 seq 1 [preauth]

Connection closed by 10.120.102.56 [preauth]

(...)

From Chris’ Miscellanea

It seems that OpenSSH recently had removed an ancient method of key exchange, as is to be read on this thread on the misc@OpenBSD mailing list.

If you open putty 's session configuration and move the "Diffie-Hellmann group exchange" right to the bottom of the "Algorithm selection policy" (Configuration / Connection / SSH / Kex), everything works again.

From Chris’ Miscellanea

SDM220 Power Meter, MODBUS, Python, RS485

The Eastron SDM220 is a very inexpensive one-phase power/energy meter, which can be readout via RS485. I got myself one to play with, and there are a few observations I wanted to write down.

From Chris’ Miscellanea

From Chris’ Miscellanea

From Chris’ Miscellanea

It's actually a pretty nifty meter, measuring power and energy in both directions, voltage and line frequency. Furthermore it outputs power-factor (cosϕ) and reactive or apparent power (which is basically the same thing, just represented differently).

One thing that cost me some time to resolve, especially as I used a selfmade RS485 adapter in the first place about the correctnes of which I was unsure are: The RS485 terminals are wired incorrectly, B and A are swapped, this has been verified with an industrial/commercial interface. Connectors 7, 8 and 9 are GND, A and B. In that order. If the link is idle, B will be positive with respect to A.

There's an existing modbus library for Python (pymodbus) which works perfect, so far. The serial modbus link is instantiated like this (if the modbus runs with parity = None).

    cl = pymodbus.client.sync.ModbusSerialClient('rtu',
        port='/dev/ttyUSB1', baudrate=9600,
        parity='N',stopbits=2,
        timeout=0.125)

The values stored in the device are actually IEEE754 floating point values, which can be converted to python floats very conveniently, they are fetched as two consecutive 16bit register, concatenated to a 32bit field, and then reinterpreted as the 32bit float:

    resp = client.read_input_registers(basereg,2, unit=1)

    return struct.unpack('>f',struct.pack('>HH',*resp.registers))

The documentation for the SDM220 is actually quite comprehensive, but it took me quite a while until I really figured out what they meant... So here are the register numbers I sucessfully used to get date off the device:

        # Symbol    Reg#  Format
        ( 'V',      0x00, '%6.2f' ), # Voltage [V]
        ( 'Curr',   0x06, '%6.2f' ), # Current [A]
        ( 'P[act]', 0x0c, '%6.0f' ), # Active Power ("Wirkleistung") [W]
        ( 'P[app]', 0x12, '%6.0f' ), # Apparent Power ("Scheinl.") [W]
        ( 'P[rea]', 0x18, '%6.0f' ), # Reactive Power ("Blindl.") [W]
        ( 'PF',     0x1e, '%6.3f' ), # Power Factor   [1]
        ( 'Phi',    0x24, '%6.1f' ), # cos(Phi)?      [1]
        ( 'Freq',   0x46, '%6.2f' )  # Line Frequency [Hz]