Requested sample rate versus playback sample rate

Support Forum PolyBian Requested sample rate versus playback sample rate

This topic contains 28 replies, has 2 voices, and was last updated by  VoltaStream 1 year ago.

Viewing 14 posts - 16 through 29 (of 29 total)
  • Author
    Posts
  • #1024

    djagab
    Participant

    No devices that might be related to this ir_rec section. Just the following:
    event0 input0 mice

    Best Regards,

    P.

    #1025

    VoltaStream
    Keymaster

    According to the driver code it should be within input0…

    You can also check with e.g.
    dmesg | grep ir
    if anything gets logged during startup.

    Will have a deeper look into it tomorrow.

    Best wishes,
    Philip.

    #1026

    djagab
    Participant

    I have looked inside input0. It only contains information about a power button device.
    dmesg | grep ir only returns irq related stuff, but no infrared device (error) messages.
    I also added an optional line to the dts ir section: linux,rc-map-name = “rc-rc6-mce”; as an example to see if this improves anything. No luck, unfortunately.

    Best Regards,

    Patrick

    #1027

    VoltaStream
    Keymaster

    Hi Patrick,

    okay, I found the problem. Although all LIRC related stuff was enabled in the defconfig one specific dependency was missing. Unfortunately no LIRC drivers were built into the kernel and the device-tree entry had no effect.
    THIS commit solves the problem and I can confirm that the lirc gpio driver now gets loaded when enabled via dt. Haven’t had the chance yet to try IR reception as I’ve got no receiver currently but it looks like it should work now.
    Nevertheless I’ve found a little mistake in your dt snippet.

    MX6UL_PAD_ENET2_TX_DATA1_GPIO2_IO12

    should actually be

    MX6UL_PAD_ENET2_TX_DATA1__GPIO2_IO12

    So one “_” was missing.

    Best wishes,
    Philip.

    #1028

    djagab
    Participant

    Thank you for the update. It looks promissing! I will give it a try as soon as I get my tool chain in order. Right now kernel builds fail with “redefinition of typedef …” errors. I’ll have to check my gcc version. As soon as I get this up and running I’ll connect a IR receiver and let you know the results.

    Best regards,

    Patrick

    #1029

    djagab
    Participant

    Hi Philip,
    The errors I encounter during kernel build are rather sticky. Meaning: a gcc update does not fix the “redefinition of typedef …”” error messages. This could mean the source has some issues, or I use a slightly different toolchain. What toolchain (not Yocto based) do you recommend for performing a kernel build using commands mentioned in THIS post? Please include, linux flavour, architecture x86 or 64, built essential, gcc version, etcetera.

    Thanks for you help.

    Best Regards

    Patrick

    #1030

    VoltaStream
    Keymaster

    Hi Patrick,

    strange that you are having problems compiling the kernel.
    I’m using a standard Ubuntu 16.04 x64 installation in VirtualBox.
    As far as I can remember I installed the toolchain with

    sudo apt-get install gcc-arm-linux-gnueabi lzop

    and entered the steps like already in the other post mentioned.

    git clone https://github.com/PolyVection/linux-imx/
    cd linux-imx
    git checkout imx_4.1.15_2.1.0_ga_PV
    export ARCH=arm
    export CROSS_COMPILE=arm-linux-gnueabi-
    make -j 6 imx_v7_PV_defconfig
    make -j 6
    make -j 6 INSTALL_MOD_PATH=/path/to/folder modules_install 

    Does that not work for you?
    If not, I’ll setup a new VM and document all steps needed right from the beginning.

    Best wishes,
    Philip.

    #1031

    djagab
    Participant

    HI,

    Thanks for the reply. I made a new toolchain, based on Ubuntu 16.04 x64, like yours and I can confirm it is working now!
    I can build the kernel modules using the commands above successfully. I had to issue the command apt-get install gcc-arm* in stead of gcc-arm-linux-gnueabi which is not a valid package according to the package manager.
    Before this, I used an OpenSuse 13.1 environment to build the kernel without success. It probably has some settings set more strict when it come to allowing redefinitions of typedefs. On the Ubuntu environment after kernel build, a folder is created containing firmware and modules. Which I have to move over to the voltastream device. Isn’t it necessary to create a new [z|u]image a well?

    Anyway, I am gonna add the infrared modifications needed to the dts file, rebuild the dtb, move all (including modules )to the voltastream zero, connect an Infrared sensor and see if I can get it working. I will let you know.

    Thanks again for the help. It is very much appreciated.

    Best regards,

    Patrick

    #1032

    VoltaStream
    Keymaster

    Hi Patrick,

    okay, good to know that it’s working with Ubuntu 1604 now.
    After the first compilation process is finished you can find the new zImage in arch/arm/boot and the device-tree binaries in /arch/arm/boot/dts.
    In the next step you are generating the modules which will be shipped to the folder mentioned in the cmd line parameter.
    Afterwards you copy the zImage and the both dtb’s to the /boot folder of the SD card and the whole modules folder to /lib/modules.
    zImage version and modules folder name always need to match. Don’t touch the firmware folder as there are the binary blobs for the wifi drivers that aren’t part of the Kernel build.
    If you only like to change the device-tree you neither have to copy over the modules nor the zImage.

    Always happy to help.

    Best wishes,
    Philip.

    #1033

    djagab
    Participant

    Hi Philip,

    Thanks again for your help. I now have rebuild the kernel and put all the files in the right place. I noticed the presence of the following items:

    /sys/class/input/
    input1, input2 all point to a device gpio_ir_recv and the folders show signs of lirc0.

    /dev/input/
    shows signs of a platform-ir-receiver-event

    So thats a good thing.

    I found the following: /sys/bus/platform/devices/ir-receiver/of_node
    It contains items from the infrared section in the device tree but a “cat gpios” doesn’t show anything.

    How do I know if the GPIO (2 12) was correctly assigned to one of these devices?
    Thanks.

    Best regards,

    Patrick

    #1034

    djagab
    Participant

    One additional positive note:
    The infrared receiver is working! I connected an OS-1838B to the chosen GPIO pin2_12 (imx pin 44) and just watched the output of /dev/lirc0 with cat /dev/lirc0. It is outputting something when I press the rc5 remote button. So the routing is all okay. I just would like to know how I can verify this in the linux environment.

    #1035

    VoltaStream
    Keymaster

    Hi Patrick,

    great to hear that you’ve got it working!
    Not sure what you mean with “verify this in linux environment”. From what you have written I understand that you connected the IR receiver to the mentioned GPIO pin and now you are able to see the received data in /dev/lirc0. In the device-tree you connected the GPIO2_12 pin to the lirc driver. What else you’d like to verify?
    Rather than using cat on /dev/lirc0 you can also test the functionality with lirc’s mode2 tool.

    Best wishes,
    Philip.

    #1036

    djagab
    Participant

    Yeah, It’s a real joy to do this 😉 I indeed used lirc’s mode2 tool to see what happens in raw mode and it receives the pulse/pause time values correctly.
    I taught my remote control which is an rc003 from Marantz, with irrecord. It has some buttons that are ment for a Marantz network player which I don’t have and would like to use for my DIY player. It works well 😉
    Now for my question about how to verify if the GPIO was correctly assigned:

    In linux I found the path: /sys/bus/platform/devices/ir-receiver/of_node
    This folder contents resembles the hierarchy used in the device tree file.
    I would however expect to see a gpio pin assignment value being returned when entering “cat gpios” in the above mentioned folder. It does not. Could be my mistake. It’s not that big a issue. Just out of curiousity.

    Although I am very pleased with the sound quality of the onboard PCM5121, I am now going to attach an es9023 based DAC, just to make a comparison. When it’s finished, I’ll upload a picture of my setup 😉

    #1040

    VoltaStream
    Keymaster

    Yes, it always gives satisfaction when it finally works as expected. 🙂
    Not sure if I can help you that much with your gpio verification check. Will have a look into it myself and report back if I’ll find something.

    Great. Some pictures are always nice! 🙂

Viewing 14 posts - 16 through 29 (of 29 total)

You must be logged in to reply to this topic.