1 / 21

Final Year Project Progress January 2007

Final Year Project Progress January 2007. By Daire O’Neill 4EE. Overview of progress to date.

osgood
Download Presentation

Final Year Project Progress January 2007

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Final Year Project Progress January 2007 By Daire O’Neill 4EE

  2. Overview of progress to date • Have installed Ubuntu and become familiar with the basics: using shell commands,configuring for internet, installing tarballs and rpm packages. Have also used open source audio programs successfully, implementing JACK and ALSA • Have done research and developed ideas to solve the issue of synchronisation of audio files • Have investigated using Python for writing additional scripts, for open source programs • Currently setting up basic FTP client/server network, for transfer of audio files

  3. Synchronisation of audio files • An issue that was previously highlighted was the accurate synchronisation of audio files • Due to variations in clock speeds on different computers, an audio file recorded on a PC may not play back with precisely the same speed on a different PC • The difference is small enough not to be noticed for normal playback, but is an issue when synchronising multiple files for longer playback

  4. Synchronisation of audio files • One solution may be to provide a front-end hardware device for capture of audio into the digital domain • Provided that the interface is manufactured within sufficiently strict limits, the timing characteristics for 2 interfaces should be very similar for a given audio signal

  5. Hardware interface • An interface such as this may comprise of a high quality ADC chip, microphone and line level inputs, volume control and level indicator • By connecting with a PC via a USB (or Firewire) interface, it works with the software to record an analogue signal and transfer the digital stream to the hard disk of the PC for storage • To complete feasibility report on such an interface…

  6. Synchronisation of audio files • Once accurate capture of the audio signal has been achieved, synchronised playback of various audio files is possible even with different PCs and clock speeds. • This is because the playback of each audio file is always driven from the same clock, so the different files will playback in sync relative to each other.

  7. Synchronisation of audio files • A file that was downloaded from the internet (where it was recorded and uploaded by a different user) may play back on your machine at a slightly slower speed than which it was originally recorded • But, it will be synchronised with the measure ( of the playback software, provided that the original digital capture was accurate. • To explain this in more detail…

  8. Example: Synchronisation

  9. Capture Recording Software Audio Sample Sample Data Sample No. Voltage Measure 200 1.87654 V 3.255 beats

  10. Capture • As well as recording the value of the audio signal (voltage) for each sample instant, the value of the measure (number of beats) for that sample is also stored: Sample No. Voltage Measure 200 1.87654 V 3.255 beats

  11. Playback • In most audio playback devices, a collection of audio samples is stored in a buffer, and are reproduced (converted back to analogue) at the same rate at which they were captured, e.g 44.1 kHz for most digital audio • Variations in clock speed, (i.e. the consistency of the 44.1 khz rate) produce timing problems when playing back multiple samples for synchronisation

  12. Solution? • A different approach is required for successful synchronisation… • Rather than letting the clock “just run”, samples should be played back and aligned according to their position in the ‘measure’ at which they were captured • Once the capture is accurate (achieved by using standard interfaces), then any sample captured in this way should play back accurately on any PC running the same software

  13. Playback Measure 3.249 3.250 3.251 3.252 3.253 3.254 3.255 3.256 3.257 Signal Sample No. Voltage Measure Sample Data 200 1.87654 V 3.255 beats

  14. Synchronisation of audio files • So, regardless of the variation in clock speed on playback, accurate timing is provided due to each sample being ‘tagged’ with the value of the measure (beats) at each sample instant-this will not vary between machines running the same software • A different clock speed will result in the overall collection of samples being played faster or slower than normal (different sampling rate), but all samples will be synchronised relative to each other

  15. Another example • Another example of using a variable sampling rate can be shown with the issue of ‘network speakers’-speakers that have an Ethernet or wireless connection to receive a digital stream, which is then converted to analogue and output as sound • A significant delay (greater than 30 ms) between these 2 audio streams (left and right channels) can produce an audible echo, or Haas effect

  16. Synchronisation of audio files • The solution is to use a dynamic sampling rate for playback, that changes (speeds audio up or down) to compensate for the difference in timing between the audio files

  17. I am currently in the process of setting up a basic FTP client/server system in Ubuntu. Vsftpd is the software I plan to use to implement this Networking

  18. File Transfer Protocol (FTP)

  19. Questions or recommendations?

More Related