কিছুক্ষণ আগে আমরা লিখেছেন আমরা কীভাবে STM32F4-ডিসকভারিতে 1 MB রম এবং 192 KB RAM সহ একটি SIP ফোন চালু করতে পেরেছি। এমবক্স. এখানে এটি অবশ্যই বলা উচিত যে সেই সংস্করণটি ন্যূনতম ছিল এবং দুটি ফোন সরাসরি সার্ভার ছাড়াই এবং শুধুমাত্র একটি দিকে ভয়েস ট্রান্সমিশনের সাথে সংযুক্ত ছিল। অতএব, আমরা সার্ভারের মাধ্যমে একটি কল সহ একটি আরও সম্পূর্ণ ফোন চালু করার সিদ্ধান্ত নিয়েছি, উভয় দিকেই ভয়েস ট্রান্সমিশন, কিন্তু একই সময়ে সম্ভাব্য মেমরি আকারের মধ্যে রাখা।
ফোনের জন্য, একটি অ্যাপ্লিকেশন বেছে নেওয়ার সিদ্ধান্ত নেওয়া হয়েছিল simple_pjsua PJSIP লাইব্রেরির অংশ হিসেবে। এটি একটি ন্যূনতম অ্যাপ্লিকেশন যা সার্ভারে নিবন্ধন করতে পারে, কল গ্রহণ করতে এবং উত্তর দিতে পারে। নীচে আমি অবিলম্বে STM32F7-ডিসকভারিতে কীভাবে এটি চালাতে হয় তার একটি বিবরণ দেব।
00:00:12.870 pjsua_acc.c ....SIP outbound status for acc 0 is not active
00:00:12.884 pjsua_acc.c ....sip:[email protected]: registration success, status=200 (Registration succes
00:00:12.911 pjsua_acc.c ....Keep-alive timer started for acc 0, destination:91.121.209.194:5060, interval:15s
সবশেষে, অডিও আউটপুটে স্পিকার বা হেডফোন ঢোকানো এবং ডিসপ্লের পাশে দুটি ছোট MEMS মাইক্রোফোনে কথা বলা বাকি। আমরা সহজ_pjsua, pjsua অ্যাপ্লিকেশনের মাধ্যমে লিনাক্স থেকে কল করি। ভাল, অথবা আপনি অন্য কোন ধরনের লিনফোন ব্যবহার করতে পারেন।
সুতরাং, প্রাথমিকভাবে একটি হার্ডওয়্যার প্ল্যাটফর্ম বেছে নেওয়ার বিষয়ে প্রশ্ন উঠেছে। যেহেতু এটা স্পষ্ট যে STM32F4-Discovery মেমরি থেকে ফিট হবে না, STM32F7-Discovery বেছে নেওয়া হয়েছিল। তার একটি 1 MB ফ্ল্যাশ ড্রাইভ এবং 256 KB RAM রয়েছে (+ 64 বিশেষ দ্রুত মেমরি, যা আমরাও ব্যবহার করব)৷ এছাড়াও সার্ভারের মাধ্যমে কলের জন্য অনেক কিছু নয়, তবে আমরা ফিট করার চেষ্টা করার সিদ্ধান্ত নিয়েছি।
শর্তসাপেক্ষে, কাজটি বিভিন্ন পর্যায়ে বিভক্ত ছিল:
QEMU তে PJSIP চলছে। এটি ডিবাগিংয়ের জন্য সুবিধাজনক ছিল, এছাড়াও আমাদের কাছে ইতিমধ্যেই সেখানে AC97 কোডেক সমর্থন ছিল।
QEMU এবং STM32-এ ভয়েস রেকর্ডিং এবং প্লেব্যাক।
একটি অ্যাপ্লিকেশন পোর্টিং simple_pjsua PJSIP থেকে। এটি আপনাকে SIP সার্ভারে নিবন্ধন করতে এবং কল করতে দেয়।
আপনার নিজের Asterisk-ভিত্তিক সার্ভার স্থাপন করুন এবং এটিতে পরীক্ষা করুন, তারপর sip.linphone.org এর মতো বাহ্যিকগুলি চেষ্টা করুন
এমবক্সে সাউন্ড পোর্টঅডিওর মাধ্যমে কাজ করে, যা PISIP-এও ব্যবহৃত হয়। QEMU-তে প্রথম সমস্যা দেখা দিয়েছে - WAV 44100 Hz এ ভাল খেলেছে, কিন্তু 8000-এ স্পষ্টতই কিছু ভুল হয়েছে। দেখা গেল যে এটি ফ্রিকোয়েন্সি সেট করার বিষয় ছিল - ডিফল্টরূপে এটি সরঞ্জামগুলিতে 44100 ছিল এবং এটি প্রোগ্রামগতভাবে পরিবর্তিত হয়নি।
এখানে, সম্ভবত, সাধারণভাবে শব্দটি কীভাবে বাজানো হয় তা কিছুটা ব্যাখ্যা করার মতো। সাউন্ড কার্ডটি মেমরির একটি অংশে কিছু পয়েন্টারে সেট করা যেতে পারে যেখান থেকে আপনি একটি পূর্বনির্ধারিত ফ্রিকোয়েন্সিতে প্লে বা রেকর্ড করতে চান। বাফার শেষ হওয়ার পরে, একটি বিঘ্ন তৈরি হয় এবং পরবর্তী বাফারের সাথে সঞ্চালন চলতে থাকে। আসল বিষয়টি হল এই বাফারগুলি আগে থেকে পূরণ করা দরকার যখন আগেরটি চালানো হচ্ছে। আমরা STM32F7 এ আরও এই সমস্যার মুখোমুখি হব।
এরপরে, আমরা একটি সার্ভার ভাড়া নিয়ে তাতে অ্যাস্টারিস্ক স্থাপন করেছি। যেহেতু এটি অনেক ডিবাগ করার প্রয়োজন ছিল, কিন্তু আমি মাইক্রোফোনে বেশি কথা বলতে চাইনি, এটি স্বয়ংক্রিয় প্লেব্যাক এবং রেকর্ডিং করা প্রয়োজন ছিল। এটি করার জন্য, আমরা simple_pjsua প্যাচ করেছি যাতে আপনি অডিও ডিভাইসের পরিবর্তে ফাইল স্লিপ করতে পারেন। PJSIP-এ, এটি বেশ সহজভাবে করা হয়, যেহেতু তাদের কাছে একটি পোর্টের ধারণা রয়েছে, যা একটি ডিভাইস বা একটি ফাইল হতে পারে। এবং এই পোর্টগুলি নমনীয়ভাবে অন্যান্য পোর্টের সাথে সংযুক্ত করা যেতে পারে। আপনি আমাদের pjsip কোড দেখতে পারেন সংগ্রহস্থল. ফলস্বরূপ, স্কিমটি নিম্নরূপ ছিল। Asterisk সার্ভারে, আমি দুটি অ্যাকাউন্ট শুরু করেছি - Linux এবং Embox-এর জন্য। এরপরে, কমান্ডটি Embox-এ কার্যকর করা হয় simple_pjsua_imported, Embox সার্ভারে নিবন্ধন করে, তারপরে আমরা Linux থেকে Embox কল করি। সংযোগের মুহুর্তে, আমরা Asterisk সার্ভারে চেক করি যে সংযোগটি প্রতিষ্ঠিত হয়েছে, এবং কিছুক্ষণ পরে আমাদের Embox-এ Linux থেকে শব্দ শোনা উচিত, এবং Linux-এ আমরা Embox থেকে চালানো ফাইলটি সংরক্ষণ করি।
এটি QEMU-তে কাজ করার পরে, আমরা STM32F7-Discovery-এ পোর্ট করার দিকে এগিয়ে গেলাম। প্রথম সমস্যা হল যে তারা ইমেজের আকারের জন্য সক্রিয় কম্পাইলার অপ্টিমাইজেশান "-Os" ছাড়া 1 MB এর ROM-এ ফিট করেনি। এজন্য আমরা "-Os" অন্তর্ভুক্ত করেছি। আরও, প্যাচটি C++ এর জন্য সমর্থন নিষ্ক্রিয় করেছে, তাই এটি শুধুমাত্র pjsua-এর জন্য প্রয়োজন, এবং আমরা simple_pjsua ব্যবহার করি।
বসানোর পর simple_pjsua, সিদ্ধান্ত নিয়েছে যে এখন এটি চালু করার সুযোগ রয়েছে। তবে প্রথমে ভয়েসের রেকর্ডিং এবং প্লেব্যাক নিয়ে কাজ করা দরকার ছিল। প্রশ্ন হল কোথায় লিখব? আমরা বাহ্যিক মেমরি বেছে নিয়েছি - SDRAM (128 MB)। আপনি নিজে এটি চেষ্টা করতে পারেন:
16000 Hz এর ফ্রিকোয়েন্সি এবং 10 সেকেন্ডের সময়কাল সহ একটি স্টেরিও WAV তৈরি করে:
record -r 16000 -c 2 -d 10000 -m C0000000
আমরা হারিয়েছি:
play -m C0000000
এখানে দুটি সমস্যা আছে। কোডেক সহ প্রথমটি - WM8994 ব্যবহার করা হয়, এবং এটিতে একটি স্লটের মতো জিনিস রয়েছে এবং এই স্লটের মধ্যে 4টি রয়েছে৷ সুতরাং, ডিফল্টরূপে, যদি এটি কনফিগার করা না থাকে, তাহলে অডিও চালানোর সময়, চারটি স্লটেই প্লেব্যাক ঘটে . অতএব, 16000 Hz এর ফ্রিকোয়েন্সিতে, আমরা 8000 Hz পেয়েছি, কিন্তু 8000 Hz-এর জন্য, প্লেব্যাক কেবল কাজ করেনি। যখন শুধুমাত্র স্লট 0 এবং 2 নির্বাচন করা হয়েছিল, তখন এটি উচিত হিসাবে কাজ করে। আরেকটি সমস্যা ছিল STM32Cube-এর অডিও ইন্টারফেস, যেখানে অডিও আউটপুট SAI (সিরিয়াল অডিও ইন্টারফেস) এর মাধ্যমে অডিও ইনপুটের সাথে সিঙ্ক্রোনাসভাবে কাজ করে (আমি বিশদটি বুঝতে পারিনি, তবে দেখা যাচ্ছে যে তারা একটি সাধারণ ঘড়ি ভাগ করে এবং যখন অডিও আউটপুট আরম্ভ করা হয়, অডিও একরকম এটি প্রবেশদ্বার সংযুক্ত করা হয়)। অর্থাৎ, আপনি এগুলিকে আলাদাভাবে চালাতে পারবেন না, তাই আমরা নিম্নলিখিতটি করেছি - অডিও ইনপুট এবং অডিও আউটপুট সর্বদা কাজ করে (বিঘ্নিত হওয়া সহ)। কিন্তু যখন সিস্টেমে কিছুই চালানো হচ্ছে না, তখন আমরা কেবল অডিও আউটপুটে একটি খালি বাফার স্লিপ করি এবং প্লেব্যাক শুরু হলে, আমরা সততার সাথে এটি পূরণ করতে শুরু করি।
আরও, আমরা এই সত্যটির সম্মুখীন হয়েছি যে ভয়েস রেকর্ডিংয়ের সময় শব্দটি খুব শান্ত ছিল। এটি এই কারণে যে STM32F7-ডিসকভারিতে MEMS মাইক্রোফোনগুলি 16000 Hz-এর নীচে ফ্রিকোয়েন্সিতে ভালভাবে কাজ করে না৷ অতএব, আমরা 16000 Hz সেট করি, এমনকি যদি 8000 Hz আসে। এটি করার জন্য, যদিও, এটি একটি ফ্রিকোয়েন্সি অন্য একটি সফ্টওয়্যার রূপান্তর যোগ করার প্রয়োজন ছিল.
এর পরে, আমাকে র্যামে অবস্থিত গাদাটির আকার বাড়াতে হয়েছিল। আমাদের হিসাব অনুযায়ী, pjsip-এর প্রয়োজন প্রায় 190 KB, এবং আমাদের কাছে মাত্র 100 KB বাকি আছে। এখানে আমাকে কিছু বাহ্যিক মেমরি ব্যবহার করতে হয়েছিল - SDRAM (প্রায় 128 KB)।
এই সমস্ত সম্পাদনা করার পরে, আমি লিনাক্স এবং এমবক্সের মধ্যে প্রথম প্যাকেজগুলি দেখেছিলাম এবং আমি শব্দ শুনেছিলাম! তবে শব্দটি ভয়ানক ছিল, QEMU-এর মতো নয়, কিছু বের করা অসম্ভব ছিল। তারপর আমরা ভাবলাম ব্যাপারটা কি হতে পারে। ডিবাগিং দেখিয়েছে যে এমবক্সের অডিও বাফারগুলি পূরণ/আনলোড করার সময় নেই। pjsip যখন একটি ফ্রেম প্রসেস করছিল, তখন 2টি ইন্টারাপ্ট বাফার প্রসেসিং সম্পূর্ণ হওয়ার সময় ছিল, যা অনেক বেশি। গতির জন্য প্রথম চিন্তা ছিল কম্পাইলার অপ্টিমাইজেশান, কিন্তু এটি ইতিমধ্যেই পিজেএসআইপি-তে অন্তর্ভুক্ত ছিল। দ্বিতীয়টি একটি হার্ডওয়্যার ফ্লোটিং পয়েন্ট, আমরা এটি সম্পর্কে কথা বলেছি প্রবন্ধ. কিন্তু অনুশীলন দেখানো হয়েছে, FPU গতিতে উল্লেখযোগ্য বৃদ্ধি দেয়নি। পরবর্তী পদক্ষেপটি ছিল থ্রেডকে অগ্রাধিকার দেওয়া। Embox এর বিভিন্ন সময়সূচী কৌশল রয়েছে এবং আমি এমন একটি অন্তর্ভুক্ত করেছি যা অগ্রাধিকার সমর্থন করে এবং অডিও স্ট্রীমকে সর্বোচ্চ অগ্রাধিকারে সেট করে। এটিও সাহায্য করেনি।
পরবর্তী ধারণাটি ছিল যে আমরা বাহ্যিক মেমরির সাথে কাজ করছি এবং সেখানে এমন স্ট্রাকচারগুলি সরানো ভাল হবে যেগুলি প্রায়শই অ্যাক্সেস করা হয়। আমি কখন এবং কিসের অধীনে একটি প্রাথমিক বিশ্লেষণ করেছি simple_pjsua মেমরি বরাদ্দ করে। দেখা গেল যে 190 Kb এর মধ্যে, প্রথম 90 Kb PJSIP-এর অভ্যন্তরীণ প্রয়োজনের জন্য বরাদ্দ করা হয়েছে এবং সেগুলি প্রায়শই অ্যাক্সেস করা হয় না। আরও, একটি ইনকামিং কলের সময়, pjsua_call_answer ফাংশনটি কল করা হয়, যেখানে বাফারগুলি ইনকামিং এবং আউটগোয়িং ফ্রেমের সাথে কাজ করার জন্য বরাদ্দ করা হয়। এটি এখনও প্রায় 100 Kb ছিল। এবং তারপর আমরা নিম্নলিখিত কি. কলের মুহূর্ত পর্যন্ত, আমরা বাহ্যিক মেমরিতে ডেটা রাখি। কল করার সাথে সাথে, আমরা অবিলম্বে গাদাটিকে অন্য একটি দিয়ে প্রতিস্থাপন করি - RAM এ। এইভাবে, সমস্ত "গরম" ডেটা দ্রুত এবং আরও অনুমানযোগ্য মেমরিতে স্থানান্তরিত হয়েছিল।
ফলে এই সব মিলে লঞ্চ করা সম্ভব হয়েছে simple_pjsua এবং আপনার সার্ভারের মাধ্যমে কল করুন। এবং তারপর অন্যান্য সার্ভার যেমন sip.linphone.org এর মাধ্যমে।
তথ্যও
ফলে উৎক্ষেপণ সম্ভব হয়েছে simple_pjsua সার্ভারের মাধ্যমে উভয় দিকে ভয়েস ট্রান্সমিশন সহ। অতিরিক্ত ব্যয় করা 128 KB SDRAM এর সমস্যাটি কিছুটা বেশি শক্তিশালী Cortex-M7 ব্যবহার করে সমাধান করা যেতে পারে (উদাহরণস্বরূপ, 32 KB RAM সহ STM769F512NI), কিন্তু একই সময়ে, আমরা এখনও 256-এ যাওয়ার আশা ছেড়ে দেইনি। KB 🙂 কেউ আগ্রহী হলে আমরা খুশি হব, বা আরও ভাল, চেষ্টা করে দেখুন। সব সূত্র, যথারীতি, আমাদের মধ্যে আছে সংগ্রহস্থল.