Go Back   Home > Forums > > >
Home Forums Rules Articles diyAudio Store Blogs Gallery Wiki Register Donations FAQ Calendar Search Today's Posts Mark Forums Read

Twisted Pear Superior quality electronic kits

Reply
 
Thread Tools Search this Thread
Old 4th March 2019, 12:25 AM   #111
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
I found your GitHub page, twluke...

To initialize your DAC at a low (safer) volume, change line 45 and 48 from:
Code:
    bus.write_byte_data(0x48, 0x18, volume) # Master volume - starts low
    bus.write_byte_data(0x48, 0x19, 0xff)
    bus.write_byte_data(0x48, 0x1a, 0xff)
    bus.write_byte_data(0x48, 0x1b, 0x7f)
to:
Code:
    bus.write_byte_data(0x48, 0x18, 0xff)
    bus.write_byte_data(0x48, 0x19, 0xff)
    bus.write_byte_data(0x48, 0x1a, 0xff)
    bus.write_byte_data(0x48, 0x1b, volume) # Master volume - starts low
Up on your line 14, you can change the '5' to whatever starting volume you prefer. Remember that 127 is -0dB.

I am listening now using your Buffalo III settings and they are working perfectly w/ PCM! I updated the Cronus board in my system and brought the MCLK to the B3PROs via Teleporter. I can't make a fair comparison of SQ because I'm repairing and updating a number of little things. New buffered headphone outputs are now 'burning-in', and the SQ results are slowly reaching "seriously good"!

Interestingly, I am hearing loud pops when recording sample rates change - and that happens even with auto-mute ON. What are your observations on that problem?

Cheers,

Frank
  Reply With Quote
Old 4th March 2019, 09:06 AM   #112
twluke is offline twluke  Japan
diyAudio Member
 
Join Date: Nov 2012
Location: Tokyo
Control of BBB-based audio appliances
Hi Frank, thank you for this kind update.
Quote:
Originally Posted by francolargo View Post
I found your GitHub page, twluke...
Good for you

Quote:
To initialize your DAC at a low (safer) volume, change line 45 and 48 from:
Code:
    bus.write_byte_data(0x48, 0x18, volume) # Master volume - starts low
    bus.write_byte_data(0x48, 0x19, 0xff)
    bus.write_byte_data(0x48, 0x1a, 0xff)
    bus.write_byte_data(0x48, 0x1b, 0x7f)
to:
Code:
    bus.write_byte_data(0x48, 0x18, 0xff)
    bus.write_byte_data(0x48, 0x19, 0xff)
    bus.write_byte_data(0x48, 0x1a, 0xff)
    bus.write_byte_data(0x48, 0x1b, volume) # Master volume - starts low
Up on your line 14, you can change the '5' to whatever starting volume you prefer. Remember that 127 is -0dB.
I revised the .py file in my repository, thank you so much.
Quote:
I am listening now using your Buffalo III settings and they are working perfectly w/ PCM! I updated the Cronus board in my system and brought the MCLK to the B3PROs via Teleporter. I can't make a fair comparison of SQ because I'm repairing and updating a number of little things. New buffered headphone outputs are now 'burning-in', and the SQ results are slowly reaching "seriously good"!
For now, I've been comparing between the 128fs and non-128fs settings to check if there is any noticeable difference in terms of the SQ but so far, I could not find any differecne so far.

BTW, the diff file between the settings above is like below:
Code:
63,64c63,64
< dac_upd 10 0xff 0x10 # 0b00010000 128fs enabled
< #dac_upd 10 0xff 0x00 # 0b00000000 128fs disabled
---
> #dac_upd 10 0xff 0x10 # 0b00010000 128fs enabled
> dac_upd 10 0xff 0x00 # 0b00000000 128fs disabled
72,73c72,73
< dac_upd 12 0xff 0x00 # 0b00000000 DPLL off 
< #dac_upd 12 0xff 0x11 # 0b00010001 Lowest BW 
---
> #dac_upd 12 0xff 0x00 # 0b00000000 DPLL off 
> dac_upd 12 0xff 0x11 # 0b00010001 Lowest BW 
85c85
< #dac_upd 15 0xff 0x09 # 0b00001001 stereo
---
> dac_upd 15 0xff 0x09 # 0b00001001 stereo
88c88
< dac_upd 15 0xff 0x0f # 0b00001111 Frank's recommend (stereo/all_to_use_ch1/vol_ctl_enabled)
---
 > #dac_upd 15 0xff 0x0f # 0b00001111 Frank's recommend (stereo/all_to_use_ch1/vol_ctl_enabled)
Quote:
Interestingly, I am hearing loud pops when recording sample rates change - and that happens even with auto-mute ON. What are your observations on that problem?

Cheers,

Frank
Ah yes, I have a similar experience, though the loudness of pops is dependent on the volume. Occasionally I'm still wondering if I have correctly understood how automute works.

From your prior post:
Quote:
In preparation, I am curious about the relationship between register 0x0a (128fs mode) and register 0x25 (bypass osf).
Does the Cronus clock always maintain the right 128fs frequency multiples?
In synch mode, wouldn't the oversampling factor (register 0x25) always be a simple integer? That wouldn't seem so consequential - whether on or off...
I checked how 128fs is defined by ESS and found that they only say that the condition can be established in sync mode with a 128*FSR MCLK in PCM normal or OSF bypass. There is no definition such as MCLK=128fs (here FSR and fs values are variable according to the modes: DSD or DoP or serial (PCM) normal or serial with OSF bypass. So, my current conclusion is that if the register for 128fs works, you are in the 128fs sync mode. If the register for 128fs is unset and there is still ordinary sound, you are in the sync mode of non-128fs.

The setting of the Cronus clocks is sometimes puzzling. I found that the 128fs condition is dependent on both of the clock divider on the cronus and the clock setting in the /boot/uEnv.txt on Botic BBB.

In my case. if I set 45/49 clocks on the uEnv.txt, the 128fs mode can be well established with x1 jumper setting on the Cronus for DSD512 but it you leave no setting in the uEnv.txt, the jumper position must be moved to x1/4 (x1/2 should be, I think, a reasonable position for 45/49 clocks). In case of 90/98 clocks, setting 45/49 in the uEnv,txt and placing the jumper to x1/4 are required for 128fs in my case. Maybe more home work is necessary for further understanding.

Best Regards,
  Reply With Quote
Old 15th March 2019, 04:14 AM   #113
Heathkit is offline Heathkit  United States
diyAudio Member
 
Join Date: May 2005
Location: Central Florida near Skycraft...
Question LED's to indicate sample rate

Moved this question from the Botic Linux driver thread...
I am using BBB with Hermes/Cronus reclocker and I2S output (no USB) to a DDDAC. Is there a way to get info from BBB or Hermes/Cronus to drive simple LED's to indicate 44.1, 88.2, 176.4, 48, 96, or 192 sample rate of the file I am playing? As a bonus, but not necessary, bit depth indication of 16 or 24 would be nice too.

Francolargo graciously offered to share his Python code that will help to accomplish this. Thanks!
__________________
Just because you can do-it-yourself, doesn't mean that you shouldn't...
  Reply With Quote
Old 15th March 2019, 04:18 AM   #114
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Greetings @Heathkit,

The code I run on my BBB is about 700 lines and almost always being revised or improved. However, my controller reports sample rate, and it is easy to accomplish using only a small sample of the code I'm running.

For GPIO setup:

First, import the Adafruit GPIO management module into the BBB.

Then, you set up your program by importing the needed modules:

Code:
#!/usr/bin/env python2.7
# -*- coding: utf-8 -*-
import select
import Adafruit_BBIO.GPIO as GPIO
import time
from multiprocessing import Process
import subprocess

# misc. GPIO setup as needed to address 7 LED outputs
# these are the pins I use with BBB/Hermes for LEDs - others are available on P8
# first, set up the pin as input or output
GPIO.setup("P8_7", GPIO.OUT)
# then, set them as low or high - to change, these are the simple commands
GPIO.output("P8_7", GPIO.LOW)
GPIO.setup("P8_9", GPIO.OUT)
GPIO.output("P8_9", GPIO.LOW)
GPIO.setup("P8_10", GPIO.OUT)
GPIO.output("P8_10", GPIO.HIGH)
GPIO.setup("P8_13", GPIO.OUT)
GPIO.output("P8_13", GPIO.LOW)
GPIO.setup("P8_15", GPIO.OUT)
GPIO.output("P8_15", GPIO.LOW)
GPIO.setup("P8_17", GPIO.OUT)
GPIO.output("P8_17", GPIO.HIGH)
GPIO.setup("P8_19", GPIO.OUT)
GPIO.output("P8_19", GPIO.LOW)
Sample rate can be read and the variable used logically as follows:

Code:
with open('/proc/asound/Botic/pcm0p/sub0/hw_params') as f:
                 lines = f.readlines()
                 try:
                     rawrate = lines[4] # the entire contents of line 4
                     rate =(int(rawrate[6:12])/1000) # characters 6-12 of line 4 in kHz
                 except IndexError:
                     rate = 0
            if rate == 0:
               self.send('no signal\n') # here you would substitute your GPIO.output lines and remove self.send()
            elif rate == 44:
               self.send('44 kHz\n')
            elif rate == 48:
               self.send('48 kHz\n')
            elif rate == 88:
               self.send('88 kHz\n')
            elif rate == 96:
               self.send('96 kHz\n')
            elif rate == 176:
               self.send('176 kHz\n')
            elif rate == 192:
               self.send('192 kHz\n')
Now you just need to set the sensor block to loop every half second or so...

Code:
While True:

   [sensor block here, all indented]

   time.sleep (0.5) #indented the same amount
  Reply With Quote
Old 15th March 2019, 04:39 AM   #115
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
and one last thing for now:

To change LEDs, you won't necessarily know which to turn off. You can define a reset function to turn all off and then just turn on the one you want as follows:

Code:
def reset():
    GPIO.output("P8_9", GPIO.LOW) # everything indented from def statement
    # add lines for all of the other pins, all indented
    # place this just above your loop
Then, change your loop if/elif statements to something like:

Code:
   elif rate == 48:
        reset()
        GPIO.output("P8_9", GPIO.HIGH)
  Reply With Quote
Old 15th March 2019, 12:50 PM   #116
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
@Heathkit,

I imagine it is unnecessary to change your sample rate LEDs very often - at least relative to the frequency of the code's frequency check. Of course you can change the timing. Also, I would run a comparison between the 'old rate' and the most recent measurement - if they are the same, then no need to reset and turn that LED on again. ...something like:

Code:
with open('/proc/asound/Botic/pcm0p/sub0/hw_params') as f:
                 lines = f.readlines()
                 try:
                     rawrate = lines[4] # the entire contents of line 4
                     rate =(int(rawrate[6:12])/1000) # characters 6-12 of line 4 in kHz
                 except IndexError:
                     rate = 0
            if rate != oldrate 
               oldrate = rate
               if rate == 0:
                  reset()
                  GPIO.output("P8_9", GPIO.HIGH) 
               elif rate == 44:
              
# ...and so forth down the list of rates and pins...
# align the following time sleep with the indentation of line 'if rate != oldrate

            time.sleep (0.5) # or whatever time you choose
You would also want to declare some value for the variable 'oldrate' before the program enters the loop. like: oldrate = 0 # positioned at the far left

Note that Python uses indentation to help organize its various functions, so you need to pay attention to the leading spaces. I'm assuming you have a bit of familiarity with Python, nano, the command line, etc. If not, no worries. We can take a step back and start from wherever you are. I am not a programmer - most of what I know about Python is from messing with BBB audio so I'm sure my code could be better optimized. But the great thing about Python is that you don't need to know 'everything' to do 'anything'.

By all means, ask questions freely...

Last edited by francolargo; 15th March 2019 at 12:53 PM.
  Reply With Quote
Old 15th March 2019, 03:41 PM   #117
Heathkit is offline Heathkit  United States
diyAudio Member
 
Join Date: May 2005
Location: Central Florida near Skycraft...
Thank you for this! I have some work to do now. Hopefully I'll be able to take it from here, but if I need any help I will be back...
__________________
Just because you can do-it-yourself, doesn't mean that you shouldn't...
  Reply With Quote
Old 16th March 2019, 09:50 PM   #118
Heathkit is offline Heathkit  United States
diyAudio Member
 
Join Date: May 2005
Location: Central Florida near Skycraft...
@Francolargo - PM sent.
__________________
Just because you can do-it-yourself, doesn't mean that you shouldn't...
  Reply With Quote
Old 17th March 2019, 06:48 AM   #119
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Quote:
Originally Posted by Heathkit View Post
@Francolargo - PM sent.
Replied
  Reply With Quote

Reply


Control of BBB-based audio appliancesHide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Adding a volume control to a TPA3122-based audio kit i336 Class D 2 9th June 2015 06:50 AM
How do I use my appliances on a Furman PL8CE? Akins Equipment & Tools 21 20th May 2015 05:24 PM
Powering non-speaker appliances with an amp cspirou Everything Else 4 4th November 2014 10:34 AM
Household Appliances repair forum Tarzan Everything Else 7 22nd August 2012 07:54 PM
Transformer-based volume control wboyd Analogue Source 4 18th August 2004 04:57 PM


New To Site? Need Help?

All times are GMT. The time now is 01:40 PM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 15.00%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
Copyright ©1999-2019 diyAudio
Wiki