Skip to main content
Topic: I2S DAC board for raspberry pi and beaglebone black (Read 78408 times) previous topic - next topic

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #15
This weekend I got PCBs back for an external clocks board. I used some of the best clocks that I know of in terms of phase noise close in, far beyond what I have observed thinking that would perhaps kill off the phase noise problem. After all the output of the BBB is some dumb FIFO that is driven as a slave from the MCLK. It should just be a set of CMOS dividers that create BCLK and LRCLK and the data well that's just a shift register with some parallel load behind it no doubt.

The results were a bit of a disappointment: basically no change. But why? And so my investigation continues...

At first I believed that somehow the SoC that is the core of the BBB must be contaminating the clocks, after all the most reasonable way of thinking about the "phase noise" observed is clock jitter. So I decided to try to make my own clocks and throw out the BBB signals except for data. To do this I wrote a tiny bit of VHDL and used a CPLD board with a 9 bit counter on it. The result is a bit surprising given the wiring mess this created:



If that isn't no change I don't know what else could be, but given what I believe the output of the SoC is I just traded basically the same circuits in CMOS for a new location in doing this.

I looked a long time at power supplies as well. Ripple on the power supplies could cause the threshold to move around a bit and cause some jitter though I bet if I formally calculated it it would be not enough to worry about (unless the power supply was much worse than it is). This didn't show up anything either. I only went down this track because my best result was made using a floating USB powered port on a laptop.

Which brings me to my next test. I had done the USB I2S interface test under windows just because my GPIB scripts are under windows with python XY. I have been running all the BBB and rPi testing for some time now using Arch and I have an Arch Linux laptop. I had already seen that the result of trying to use the best USB audio interface connected to the BBB was horrific but I was a bit concerned about if the power was enough to really keep everything stable. As a result I thought it would be very wise to check the best USB I2S interface under Arch on a powerful x86 laptop:



It is a starling result. The upper curve (blue) is from playing a FLAC file encoded 44.1 K 16-bits of the tone using ffmpeg:
ffmpeg -i test41K7p2.flac -f alsa "default:CARD=Audio" -re

for the lower curve I simply decoded the FLAC file first (http://teholabs.com/test41K7p2.flac) to a wave file using ffmpeg then played it with aplay:
aplay -Dsysdefault:CARD=Audio test41K7p2.wav

This is a pretty amazing result in some ways, I would assume the ffmpeg statement is just a pipe like construct to the same ALSA interface as aplay uses. Someone with more knowledge of Linux audio could set the record straight. This result however is the first hint that the software is mattering a lot.

While this USB interface certainly supports 48 and 44.1 K families, I didn't check if Linux was aware of this. Playing 48K files seemed to work better on the BBB. I should check exactly how it is registered but it is a low priority as the much bigger result was how important the software stack was in the results. Once I saw the per-decode difference + aplay, I had to try it on the BBB.



Using only aplay and the same file as before, I got the terrible upper curve. Then I tried a 48K file and I got the middle curve. Now note it isn't as good as the near delta function like result on the laptop! As I said I presume it is resampling (badly) the 44.1K file for this interface. The best curve is the old I2S interface on the BBB for comparison. It is a bit better.

These results are interesting. To me they point at software as being the issue rather than hardware. So my hypothesis now would be that the "phase noise" seen in all my plots up to now might be mostly software related. Even the Raspberry Pi stuff could just be the software. The indirect evidence for this is the similarity of very different DAC/PCB layouts in terms of the resulting spectra, and the huge differences with only simple changes in how Linux is supplying the hardware with data seen in the laptop data.

Unfortunately, I know far more physics and pure EE things than I do Linux software things. The evidence certainly points to the software stack probably missing samples in the stream. The only way I can think to check that at this time is to use a logic analyzer to inspect and decode the data stream, but given the spectra the corruption if that is what it is, is not that frequent. I could look at the USB case perhaps as that would be much more frequent but I care more about the onboard I2S case.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #16
Hi - fascinating read and most impressively presented but also particularly your thought processes based on sound physics.

I was initially greatly attracted to your proposal of a FPGA as the driver for the I2S stream, but gradually this seemed to morph into a Rpi or BBB project. Both SoC to me seem inferior to a hand-rolled FPGA based project by someone like you who knows how to do it properly.

Then using MPD/ALSA/Linux surely is going to 'spoil the party' before you have got any data into your domain. My experience of that replay software even with good PSU/mobo etc. is poor. Even Windows-based audio playback can be much better (MQn for instance aces MPD). Ditto the software on the BBB seems suspect, as you say.

I am an Accountant not an audio engineer, so may be missing many points!

My dream is a player not based on any mainstream OS which cannot be the right choice of OS for audio. Not using USB which has its own issues. A dedicated FPGA hardware and software platform for audiophile playback. Sounds easy, but of course is not.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #17
Thanks for the comment. The project hasn't really slipped into using BBB or r-Pi they are in the title...

I think having an FPGA or CPLD "sound card" certain is viable but really doing the whole decode of all the formats on an FPGA is probably a waste of effort. One could fairly easily write a blob of software in Linux that sent PCM data to a large buffered output over say a SPI port along with the clocking information (IE the header). In most cases SPI easily gets to 20 Mbit even on just microcontrollers. Meanwhile redbook audio is only 44100*2*16/1e6 -> 1.4 Mbit. Even 192/32bit is only 12 Mbit in stereo. We aren't talking about a ton of data here. The big problem with this approach is really the software.

Apple reminded the world that user experience counts. That really is the sticking point. I may actually be past the point where I can hear the difference myself, after all the distortion of speakers and headphones is far more than the early part of the data stream. However, someone can still hear the differences I am observing objectively.

I don't believe the SoCs are inherently jittery, particularly BBB when it is operating as a slave (it doesn't make sense that it would have a lot of jitter anyway). I think the CPLD experiment excluding the possibility that it was just the clocks that were jittering pretty well. I have also shown that, while software dependent, a linux computer using aplay gave essentially the same spectra as a windows one using the same hardware. So it likely is down to the software. As modern 1 GHz arm processor that only uses 4% of its power for decoding the file should be more than capable of delivering all the samples correctly which seems the issue. Making it so is harder than it should be though.

Also I have been thinking of using a CLPD just to test the DAC quality in the most controlled manner I can and was examining the data in a wave file at 11025 Hz where I would only need 4 samples to do a sine wave... Turns out the floating point truncation doesn't yield exactly 1, 0, -1, 0. Two pieces of software have this "issue" I don't know if the dittering is intentional or not but it will look like phase noise if you just think of the FFT of the result, and assume the DAC's rendering is perfect. This isn't the cause of my observation though as everything is using the same wave file basically.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #18
Interesting and thanks.

Quote
I have also shown that, while software dependent, a linux computer using aplay gave essentially the same spectra as a windows one using the same hardware. So it likely is down to the software. As modern 1 GHz arm processor that only uses 4% of its power for decoding the file should be more than capable of delivering all the samples correctly which seems the issue. Making it so is harder than it should be though.
I have been testing MQn player software for over a year. It runs on Windows using WASAPI output. The author has worked really hard at optimising the render loop. Users have gone to great lengths to 'optimise' the Windows platform to minimise unnecessary processes etc - myself included. The result has been amazingly good with 16/44.1 WAV/FLAC files - far more detail and fidelity that one could have ever imagined. The astonishing thing is that changing just one instruction in the render loop can make such a difference to SQ. Not subtle at all.

So far noone has been able to put an empirical explanation forward to explain why this is so marked or at all. I run a Chord DAC which has a 4 second RAM buffer reclocking the S/PDIF stream and feeding it directly to a FPGA (Xilinx) based DAC. Even with that DAC the same differences are noted so it is unlikely to be plain jitter errors.

MPD running on an optimised PC was poor quality for me, even just plain pass through with no mixing/upsampling. I conclude that it was MPD causing the poor quality, as a minimised Linux OS should be far less intrusive than 'The Bastard Windows'.

No doubt you have been following the BBB Botic cape project by Russ of Twisted Pear - http://http://www.diyaudio.com/forums/twisted-pear/250583-building-open-embedded-audio-applicance-80.html. It is nearing completion and will be very interesting to hear it and whether they have got over the software issues using a BBB.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #19
Yes I know of it. I designed the cape they needed in just a couple hours. Twisted pair audio doesn't make objective measurements of any of their designs as far as I know. If you like what they sound like then okay, but I don't have any particular interest in their project unless they are going to measure the result objectively. If I could get access to a better audio analyzer I could optimize my design more. At this point my plan is to reduce the harmonics I can see with what I have and presume the noise floor is limited by the dynamic range of my measurement device (this is a reasonable assumption), therefore I can calculate and approximate THD+N number by measuring the noise floor as a function of volume and fitting the data then add back in the harmonic content at a standard reference level. Without 5-20 K of equipment that is the best I can hope for. I believe I am basically at 0.004% THD+N right now. I haven't calculated the DNR yet, as I had to look up how that is defined by audio measures yesterday but made a measurement today to give me an idea of where I am. Then I just have to take a 2 tone spectra. I am considering switching to a Ti part now that I basically have decided not to use the r-Pi for this project and thus will have a MCLK. I can really use any DAC but I agree with the ODAC creator that a built in negative charge pump supply and voltage mode output is far easier to design with than IV stages. Audiophiles can decide what coloration they want on their music and all that, but the objective quality is the only real thing that matters if you want to color your music from the source just equalize it before it reaches the DAC in digital space.

As far as your comments on Windows software stacks, I don't know them in detail. MPD just calls ALSA if you set it up that way and FFMPEG (in my case) as the decoder. ALSA down to the I2S is all I worry about the rest of the stuff can easily be fixed.

Twisted pair audio's cape will have all of the same problems as my design in terms of performance as I have clearly shown it has nothing to do with my board's layout. If they solve the software issues great, I use the same driver for my clock board. I may release a clock board for BBB myself which I would guess would cost fraction of what Twisted Pair would ask.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #20
Hi Brian,

How do you power your BBB in these measurements? Have you tried a good linear supply?

I'll provide new Botic driver driver and SD card image in the next few days. In its kernel the PMIC of BBB will programmed to fixed frequency clock, so there will be less EMI generated by BBB itself.

Thanks for measurement. Also I'd welcome if there would be more clear descriptions what is measured.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #21
Hi Brian - your approach is exactly what I would do if I was an audio designer, which I am not. Objective management is really what it is all about at the end of the day, and IMHO virtually none of the commercial vendors base their designs on. And it shows in the end result.

If you need any testers when you get a bit further down the road, I would be very keen to help. I have what I think is a good base to measure (by ear) against MQn player, where there is a critical audience for that designer's output.

I don't know if you were thinking commercially (I am an Accountant in London), but I reckon there is a small but steadily increasing number of audiophiles who would pay for a superior end result in a DIY or near DIY market if a competitive price could be achieved. Certainly, the TP embedded BBB project is getting a lot of support at the design stage.

I will follow the project with interest.

Cheers
Jonathan

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #22
[quote author="miero"]Hi Brian,

How do you power your BBB in these measurements? Have you tried a good linear supply?

I'll provide new Botic driver driver and SD card image in the next few days. In its kernel the PMIC of BBB will programmed to fixed frequency clock, so there will be less EMI generated by BBB itself.

Thanks for measurement. Also I'd welcome if there would be more clear descriptions what is measured.[/quote]

First of all thank you so much for writing the driver for BBB to begin with Miero. I read all the code and was starting to try to think about how it all worked but I think I would need to spend a few more days at minimum to understand the ALSA audio subsystem before I could fully understand all those data structures.

As for how the BBB was powered. I had tried both normal linear power supplies (transformers + rectifier + cap) and some of my Agilent bench supplies. The I2S interface was fully isolated and the DAC was powered using a separate linear power supply that was kept constant across all the tests. The CCMR should be quite good on the digital side given how it was isolated. I know basically that some part of the I2S stream is at fault for the extra jitter. That's 99.9% certain.

I think strongly that the data stream itself is what is wrong. The thing that points is the CPLD experiment where I generated all the clocks using dividers (and got the same spectra) and the software stack changes making a difference.  If you are interested I used NZ2520SD clocks for the 2 clock sources obtained from DIYINHK. The clock PCB is minimal with just minimum length traces to the clock input pins and NPO 0603 decoupling capacitors.

I agree with you also if you have a good calibrated sound card you can do better measurements than what I can do with the Keithley THD meter, however the calibration is the tricky part if you do it that way.

If the only thing you are going to change is the power management I am not sure that will do much for what I have observed. I honestly believe it is dropping samples occasionally. Do you know how to set the PID priorities of everything from ALSA to the I2S kernel driver that you wrote to a higher level? It doesn't seem like with low utilization it should drop anything but that seems the most reasonable explanation at this time. I am running the OS off an SD card if that latency matters... I did notice the IRQs for all the different flash devices when I was trying to figure this issue out by myself.

Finally I haven't read the datasheet of the power management IC but spread spectrum frequency would generally be lower than fixed for EMI, but you probably know all about that stuff... I don't really know what you are working on just thought I should mention the obvious.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #23
[quote author="jrling"]Hi Brian - your approach is exactly what I would do if I was an audio designer, which I am not. Objective management is really what it is all about at the end of the day, and IMHO virtually none of the commercial vendors base their designs on. And it shows in the end result.

If you need any testers when you get a bit further down the road, I would be very keen to help. I have what I think is a good base to measure (by ear) against MQn player, where there is a critical audience for that designer's output.

I don't know if you were thinking commercially (I am an Accountant in London), but I reckon there is a small but steadily increasing number of audiophiles who would pay for a superior end result in a DIY or near DIY market if a competitive price could be achieved. Certainly, the TP embedded BBB project is getting a lot of support at the design stage.

I will follow the project with interest.

Cheers
Jonathan[/quote]

The project is first and foremost for myself and my family and friends who love music. However, if it meets a level I can really be proud of I will probably make it available at that time to the public with pretty full transparency of where the costs and overheads are for any production of it are. I had a company which lost money and I better understand the value of my time and the risk of having left over stock. I will at minimum release all the Gerbers and parts lists when I am satisfied I have done a good job. It already is better than my CD player I have listened to music on for 15 years. It is close to the spec of my NAD amplifier as well, once it passes that point I basically don't have anything I gain out of improving it more.

Thanks for your offer and I will keep posting here as I have time to work on it.

This has been a very fun project for me because of all the efforts of all the free software folks and I certainly want to give hardware which I am at least okay at designing back to the software community.

Brian

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #24
I missed the last line of your comment miero. More clear description of what was measured.

In almost all cases a single tone spectra at -1 dBFS was measured at 100 Hz spacing from 20 Hz to 20K and stored. The spectra were taken using a Keithley 2015 THD meter. The bin size was 20 Hz in the FFT and all numbers are just calculated off the FFT. No weighting is applied to the FFT. The low frequency noise is interesting but maybe from other things in the room.

The single tone was generated by the tone generation function in a wave editor at 32 bit resolution then reduced to 24 or 16 bit resolution file for playback. Inspection in a hex editor of the file does show rounding errors or dithering harmonics of the sample frequency (IE 11025 does not only contain 4 binary values for a 44.1 KHz file). This issue would also appear in the USB I2S stream measurement so it is not the main source of the phase noise.

The dynamic range of the 2015 limits the noise floor in the FFT for -1 dBFS. If we assume the noise other than harmonics is fixed then the SNR will remain fixed until the true noise floor is reached. I should be able to estimate the DNR and real THD+N with this assumption. Most DACs THD scale in this way (see the pcm5102a datasheet).

Comparisons to CD players were made by running them stock and playing a CD burned with the WAV file with stepped tones in it. All other comparisons were made simply by swapping the source of the I2S stream.

Originally MPD was used as the audio program decoding the file for playback (via FFMPEG). I player switched to using a bare Arch distribution with playback of wav files through aplay only. Decoding files was done before hand using FFMPEG, followed by playback of the wave file. Commands were issued via SSH. For the BBB connection was made via Ethernet. For R-Pi by WiFi dongle. The computers were powered by linear power supplies in some testing cases to try to make sure power quality was adequate to suppress jitter.

If this isn't enough information about how testing was done please ask a specific question and I will try to answer it in a more clear way.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #25
Quote
The I2S interface was fully isolated...
How did you isolate I2S? Couldn't the isolator worsen the performance?

Quote
The thing that points is the CPLD experiment where I generated all the clocks using dividers (and got the same spectra) and the software stack changes making a difference.
This is what I don't understand. Did you generate bitclock & lr-clock via CPLD and then feed it into BBB? This can be done, but the McASP controller must be properly configured. But this was not part of my driver.

Can you guess what will be a jitter intruduced by CPLD? Do you expect it will be smaller than internal dividers in the BBB?

How long I2S cables are you using? The lot of noise can be catched on long cables.

Quote
... spread spectrum frequency would generally be lower than fixed for EMI, but you probably know all about that stuff...
I've not verified that, but BBB manual states about step-down converter: "For low-noise applications the devices can be forced into fixed frequency PWM using the I2C interface."

Quote
I honestly believe it is dropping samples occasionally.
BBB and Botic driver, right? Does this also happen with 44k1Hz or 48kHz stereo streams?

If you use aplay it reports underruns, when there is not enough data to be sent to kernel. If underruns are reported then there is slow media, slow CPU for resampling/decoding or insufficient buffers sizes.

The problem could also happen in the kernel if samples are dropped without any report by aplay. For example when CPU is busy handling other interrupts (net, mmc, usb...), or when audio data rate is too high for the BBB.

The fastest file access seems be when remote storage is mounted via NFS. Then cifs (windows shares) but I had to set cache=none option to fix underruns with aplay.

Nevertheless I'm having similar issues when debugging driver 4 channels at 192kHz rate. Two channels "sound" ok, other two do not. But I'm trying to find a way at least to detect if sample was lost in the kernel...

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #26
Good luck!

Quote
My dream is a player not based on any mainstream OS which cannot be the right choice of OS for audio. Not using USB which has its own issues. A dedicated FPGA hardware and software platform for audiophile playback. Sounds easy, but of course is not.

I think your last post rather demonstrates my point about OS. Linux is an OS that is aimed at much bigger applications than just rendering PCM to a DAC. Better (less bloated) than Windows, but nevertheless has loads of threads running all competing for time of the CPU and RAM and then also slap bang in the middle of a PC/laptop environment full of RFI/EMI.  Hardly ideal however good the writer of the audio software is (Miero is very good I am sure).

A dedicated simple hardware platform like a FPGA doesn't need an OS as such. All it does is turn on and do the only thing it knows how to do all the time and timed perfectly. It does not need to be high power and very quick, because it is only doing one relatively undemanding task. The sort of platform I am referring to is well described here - http://http://ultra-embedded.com/fpga_audio although his aim was not to give top priority to audiophile performance, so I am sure could be improved upon. PSU with such a low power device ideally could be Li-ion battery with very good low noise performance.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #27
Jrling:

You are basically arguing for a real time system over a preemptive one. Yes it can be an issue in principle. But the data rate is slow slow for audio that keeping a FIFO for it full should be trivial even with a polled querying of the FIFO's status on preemptive OS. If there are no buffer underruns and the output circuit from the FIFO to the I2S pins are identical then there would be no difference between an SoC solution running a preemptive OS and a real time system on something like a micro controller or an FPGA.

Now please note I am saying the I2S circuitry is the same in this thought experiment. That's everything: the clocking, and PLLs the serializer all that stuff. That stuff is implementation dependent. At these low data rates digital stuff is actually pretty easy to get right.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #28
I do of course defer to you much greater knowledge in these matters.

But I have tried several Linux-based dedicated audio(phile) players (e.g.Squeezelite, Daphile, MPDpup) the latter two running on really cut down Linux OS and the results were not that good. I get better by a long way with MQn on Windows with exactly the same PC and replay chain.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #29
[quote author="miero"]How did you isolate I2S? Couldn't the isolator worsen the performance?[/quote]

In the general case isolation could hurt performance. In this case it was a variable that was controlled for.

There are two blobs: an isolated DAC + cables and an I2S source. the I2S source is changed, everything else is fixed. Therefore any difference observed is in the I2S source. I observe that the USB I2S source has much lower phase noise in the FFTs I took. Therefore the BBB and r-Pi I2S streams have attributes that increase the phase noise.


[quote author="miero"]This is what I don't understand. Did you generate bitclock & lr-clock via CPLD and then feed it into BBB? This can be done, but the McASP controller must be properly configured. But this was not part of my driver.

Can you guess what will be a jitter intruduced by CPLD? Do you expect it will be smaller than internal dividers in the BBB?

How long I2S cables are you using? The lot of noise can be catched on long cables.[/quote]

I already addressed the cables in the previous remark, since they are fixed they should not be the cause (assuming the LVCMOS drivers are equally able across all of the I2S sources used).

My thought when I observed the worse phase noise from the BBB was that one of the clocks must be bad. To test this hypothesis I wrote a code that replaced all of the clocks from the BBB I2S stream with ones generated from a CPLD. I did not feel this would necessarily be better, but that it could be and it should be different in all probability.

The LRCLK and BCLK were generated from the MCLK using just dividers in the CPLD. The LRCLK of the BBB and the MCLK (switched oscillators from your driver) were feed to the CPLD. The BBB-LRCLK was used to synchronize the LRCLK the CLPD was making to the "correct" one the BBB provides otherwise it wouldn't be aligned to the samples. (Think of BBB LRCLK as a one time trigger).

So I basically through away the 2 BBB clocks (BCLK and LRCLK) and used these CPLD clocks. I could do this because the I2S interface was a slave to the MCLK. The MCLK was fed to the same places in both the BBB and CPLD case.

The resulting spectra was practically identical. This is strong evidence that nothing is different with the MCLK, LRCLK and BCLK between the two cases. If the integrity of the MCLK is good then it implies the data pin is the one at fault. Hence missing samples.

This hypothesis is supported by the fact at 48 KHz using the on-board clock vs using my off-board 48 KHz low phase noise clock I think also resulted in the same spectra. This suggests the limiting factor is not the MCLK (a bad MCLK could limit all cases technically). I would have to double check this to be absolutely sure but this is what I remember from weeks ago when I did this work. I do not believe the MCLKs could be bad. The "good" I2S USB source uses the exact same clocks as I selected to used with the BBB.

That would leave only: two defective clocks (both the 48 and 44.1), thermal damage during soldering causing several orders of magnitude worse phase noise than specified, and terrible PCB layout for MCLK. I don't believe any of those are particularly likely but they are technically not excluded by the experiments done.

[quote author="miero"]
Quote
I honestly believe it is dropping samples occasionally.
BBB and Botic driver, right? Does this also happen with 44k1Hz or 48kHz stereo streams?

If you use aplay it reports underruns, when there is not enough data to be sent to kernel. If underruns are reported then there is slow media, slow CPU for resampling/decoding or insufficient buffers sizes.

The problem could also happen in the kernel if samples are dropped without any report by aplay. For example when CPU is busy handling other interrupts (net, mmc, usb...), or when audio data rate is too high for the BBB.

The fastest file access seems be when remote storage is mounted via NFS. Then cifs (windows shares) but I had to set cache=none option to fix underruns with aplay.[/quote]

I am mainly testing for red book as the majority of audio sources are red book derived. I have also tested at 48 KHz. (So basically 44.1 KHz 16 and 24 bit and 48 KHz at 16 and 24 bit with most of the testing at 44.1/16).

How do I check for the underruns? I didn't notice any messages to that effect but I might not have looked in the right place or set the right switch (I am not a linux audio expert just a physicist/EE).

Is there a way to know if the FIFO for the I2S port underruns via software? (As in it sees the empty flag on that part of the IC when it is loading the FIFO or something like that?)

Finally you mentioned something about CIFS and other network file systems. Though the commands are sent over the network. The actual file played was on the local file system (microSD card).

Is there any way to check if the kernel is dropping the samples? I agree that other interrupts could cause drops if things are not written in the best way. I don't really have anything running on the BBB except standard OS stuff and aplay. (< 5% utilization).