nikkov

Members
  • Content Count

    11
  • Joined

  • Last visited

About nikkov

  • Rank
    Member

Recent Profile Visitors

483 profile views
  1. Hi, I try working with i2s driver on last armbian (5.99 kernel 4.19.84) with nanopi neo and found trouble with I2S clock - it has very excessive jitter (see attached screen from my oscilloscope). I use small dts overlay for enable i2s and mainline i2s code without changes and with changes from codekipper, nanopi neo and neo 2 with same result, but old armbian image 5.65 (4.14.17) working without problem. I also found a mention of a similar problem on forum volumio sun8i-h3-i2s0.dts /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/"; __overlay__ { pcm5102a: pcm5102a { #sound-dai-cells = <0>; compatible = "ti,pcm5102a"; pcm510x,format = "i2s"; }; }; }; fragment@1 { target = <&i2s0>; __overlay__ { status = "okay"; pinctrl-0 = <&i2s0_pins>; sound-dai = <&pcm5102a>; pinctrl-names = "default"; }; }; fragment@2 { target-path = "/"; __overlay__ { sound_i2s { compatible = "simple-audio-card"; simple-audio-card,name = "I2S-master"; simple-audio-card,mclk-fs = <256>; simple-audio-card,format = "i2s"; status = "okay"; simple-audio-card,cpu { sound-dai = <&i2s0>; }; simple-audio-card,codec { sound-dai = <&pcm5102a>; }; }; }; }; };
  2. I checked your wip i2s driver code with my hardware and simple codec driver for my clock board. In function sun4i_i2s_set_clk_rate calculates lrck value as (clk_rate / rate / oversample_rate)*word_size and we have, eg (22579200 / 44100 / 128) * 16 = 64 of BCLKs within each channel. But in stereo i2s mode lrck value must be equal slot width. In stable version lrck fixed and equal 32. After I replace calculated value lrck to fixed 32 I successfully played 16/24 bit sample.
  3. Yes, I found this values in A20 user manual. But it's related only for master mode i2s which clocked by PLL, and can't used for external clock and slave mode bus. So we must check oversample value only for master mode!
  4. Yes, your debug output I see in kernel.log For full-fledged testing, I need to add a codec driver to specify the hardware modes for my clocks board: i2s mode; 32 bit frame size independents from sample size; divider for BCLK/LRCLK driven by GPIO. I'll try made this in near time.
  5. Quick info about testing. - nanopi neo - armbian image builded from github sources - i2s module by codekipper - overlay from codekipper's post (but simple-audio-card,mclk-fs = <128>). Because my clock board without pins control works on 176400 all test with this sample rate: aplay -c 2 -f S16_LE -r 176400 /dev/urandom - working and I see some data on dout pin aplay -c 2 -f S24_LE -r 176400 /dev/urandom - aplay: pcm_write:2011: write error: Input/output error aplay -c 2 -f S32_LE -r 176400 /dev/urandom - no error and zero data on dout pin
  6. OK, I'll built fresh armbian image for nanopi neo and can check your code. One question: why oversample rates started with 128 but not 64 (32 bit frame) or 32 (16 bit frame)?
  7. Thank you for information. I only now began to understand mainline driver. I have some hardware (cubietruck, nanopi neo and nanopi neo 2), clocks board (schematic attached) and simple logic analyzer. I can try testing your modification. neoclock - Project.pdf
  8. Slave mode assume that externals source of the bit- and lr-clocks controls by driver, but I can't saw where is it. And as I see mainline driver support only 16 bit sample. I worked with friendlyarm's variant because it was most complete. Now I want modify mainline driver for support 16/24 bit master/slave and test it on nanopi neo (2, air) and cubietruck.
  9. If you want get just play function, you can use my Volumio image for NanoPi-Neo. But unfortunately I now don't have experience with overlays now
  10. Not related to armbian, but I made some work with friendlyarm kernel 4.11.2 for support i2s driver for h3/h5 with support 16/24 bit master/slave mode i2s (link) and build Volumio image for nanopi neo (link). In future I want to get same in mainline kernel.
  11. In my latest patch fixed issue when change the track or seeking in the track only. I don't use SPDIF and I don't know exists this issue in original linux-sunxi sources or not. I have found swapping channels when recording, but I can't fix it yet.